[要約] RFC 8470は、HTTPでの早期データの使用に関するガイドラインであり、TLS 1.3の仕様に基づいています。その目的は、クライアントがTLSハンドシェイクの完了前にデータをサーバに送信できるようにすることです。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8470 Mozilla
Category: Standards Track M. Nottingham
ISSN: 2070-1721 Fastly
W. Tarreau
HAProxy Technologies
September 2018
Using Early Data in HTTP
HTTPでの初期データの使用
Abstract
概要
Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.
TLSの初期データを使用すると、リプレイ攻撃の可能性にさらされます。このドキュメントでは、初期のデータで送信されるHTTPリクエストについてクライアントがサーバーと通信できるようにするメカニズムを定義します。これらのメカニズムを使用してリプレイのリスクを軽減する手法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8470.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8470で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Early Data in HTTP . . . . . . . . . . . . . . . . . . . . . 3
3. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3
4. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 5
5. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 6
5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 7
5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 8
6.2. Consistent Handling of Early Data . . . . . . . . . . . . 9
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9
6.4. Out-of-Order Delivery . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
TLS 1.3 [TLS13] introduces the concept of early data (also known as zero round-trip time (0-RTT) data). If the client has spoken to the same server recently, early data allows a client to send data to a server in the first round trip of a connection, without waiting for the TLS handshake to complete.
TLS 1.3 [TLS13]は、初期データ（ゼロラウンドトリップ時間（0-RTT）データとも呼ばれる）の概念を導入しています。クライアントが最近同じサーバーに話しかけた場合、初期データにより、クライアントはTLSハンドシェイクの完了を待たずに、接続の最初のラウンドトリップでサーバーにデータを送信できます。
When used with HTTP [HTTP], early data allows clients to send requests immediately, thus avoiding the one or two round-trip delays needed for the TLS handshake. This is a significant performance enhancement; however, it has significant limitations.
HTTP [HTTP]と共に使用すると、初期データはクライアントが要求をすぐに送信できるようにするため、TLSハンドシェイクに必要な1つまたは2つの往復遅延を回避できます。これは大幅なパフォーマンスの向上です。ただし、大きな制限があります。
The primary risk of using early data is that an attacker might capture and replay the request(s) it contains. TLS [TLS13] describes techniques that can be used to reduce the likelihood that an attacker can successfully replay a request, but these techniques can be difficult to deploy and still leave some possibility of a successful attack.
初期のデータを使用する主なリスクは、攻撃者がそのデータに含まれるリクエストをキャプチャして再生する可能性があることです。 TLS [TLS13]は、攻撃者がリクエストを正常に再生できる可能性を減らすために使用できる手法を説明していますが、これらの手法は展開が困難であり、攻撃が成功する可能性を残す可能性があります。
Note that this is different from automated or user-initiated retries; replays are initiated by an attacker without the awareness of the client.
これは、自動化された再試行またはユーザーが開始した再試行とは異なります。リプレイは、クライアントに気付かれずに攻撃者によって開始されます。
To help mitigate the risk of replays in HTTP, this document gives an overview of techniques for controlling these risks in servers and defines requirements for clients when sending requests in early data.
HTTPでのリプレイのリスクを軽減するために、このドキュメントでは、サーバーでこれらのリスクを制御するための手法の概要を示し、リクエストを初期データで送信するときのクライアントの要件を定義します。
The advice in this document also applies to use of 0-RTT in HTTP over QUIC [HQ].
このドキュメントのアドバイスは、HTTP over QUIC [HQ]での0-RTTの使用にも適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Conceptually, early data is concatenated with other application data to form a single stream. This can mean that requests are entirely contained within early data or that only part of a request is early. In a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ], multiple requests might be partially delivered in early data.
概念的には、初期データは他のアプリケーションデータと連結されて単一のストリームを形成します。これは、リクエストが完全に初期データ内に含まれている、またはリクエストの一部のみが初期であることを意味します。 HTTP / 2 [RFC7540]やHTTP / QUIC [HQ]などの多重プロトコルでは、複数のリクエストが初期データで部分的に配信される場合があります。
The model that this document assumes is that once the TLS handshake completes, the early data received on that TLS connection is known to not be a replayed copy of that data. However, it is important to note that this does not mean that early data will not be or has not been replayed on another connection.
このドキュメントで想定しているモデルは、TLSハンドシェイクが完了すると、そのTLS接続で受信した初期のデータは、そのデータの再生されたコピーではないことがわかっていることです。ただし、これは、初期のデータが別の接続で再生されない、または再生されなかったことを意味するものではないことに注意することが重要です。
A server decides whether or not to offer a client the ability to send early data on future connections when sending the TLS session ticket.
サーバーは、TLSセッションチケットを送信するときに、将来の接続で初期データを送信する機能をクライアントに提供するかどうかを決定します。
TLS [TLS13] mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data. These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays.
TLS [TLS13]では、攻撃者が初期データを正常に再生する能力を低下させる再生検出戦略の使用を義務付けています。これらのアンチリプレイテクニックは、データがリプレイされる可能性を減らしますが完全に排除するわけではなく、リプレイ数の上限を固定します。
When a server enables early data, there are a number of techniques it can use to mitigate the risks of replay:
サーバーが初期データを有効にする場合、再生のリスクを軽減するために使用できるいくつかの手法があります。
1. The server can reject early data at the TLS layer. A server cannot selectively reject early data, so this results in all requests sent in early data being discarded.
1. サーバーはTLSレイヤーで初期データを拒否できます。サーバーは初期データを選択的に拒否できないため、初期データで送信されたすべてのリクエストが破棄されます。
2. The server can choose to delay processing of early data until after the TLS handshake completes. By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein. This provides the server with some assurance that the early data was not replayed. If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis.
2. サーバーは、TLSハンドシェイクが完了するまで、初期データの処理を遅らせることを選択できます。処理を延期することにより、正常に完了した接続のみがその中の要求に使用されるようにすることができます。これにより、初期のデータが再生されなかったことがサーバーにある程度保証されます。サーバーが初期データで複数のリクエストを受信した場合、リクエストごとにHTTP処理を延期するかどうかを決定できます。
3. The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (Section 5.2) in cases where the risk of replay is judged too great.
3. サーバーは、リプレイのリスクが大きすぎると判断された場合に、クライアントに個々のリクエストを再試行させ、425（Too Early）ステータスコード（セクション5.2）で応答することにより、早期データを使用しないようにすることができます。
All of these techniques are equally effective; a server can use the method that best suits it.
これらのテクニックはすべて同等に効果的です。サーバーはそれに最適な方法を使用できます。
For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server). The primary risk associated with using early data is in the actions a server takes when processing a request; processing a duplicated request might result in duplicated effects and side effects. Appendix E.5 of [TLS13] also describes other effects produced by processing duplicated requests.
特定のリクエストに対して、リスクを再生する許容レベルは、それが操作するリソースに固有です（したがって、オリジンサーバーのみが認識します）。初期データの使用に関連する主なリスクは、リクエストを処理するときにサーバーが実行するアクションにあります。複製されたリクエストを処理すると、結果が重複したり、副作用が発生したりすることがあります。 [TLS13]の付録E.5では、重複したリクエストの処理によって生じるその他の影響についても説明しています。
The request method's safety ([RFC7231], Section 4.2.1) is one way to determine this. However, some resources produce side effects with safe methods, so this cannot be universally relied upon.
リクエストメソッドの安全性（[RFC7231]、セクション4.2.1）は、これを判断する1つの方法です。ただし、一部のリソースでは安全な方法で副作用が発生するため、これに全面的に依存することはできません。
It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests. Absent such explicit information, origin servers MUST either reject early data or implement the techniques described in this document for ensuring that requests are not processed prior to TLS handshake completion.
オリジンサーバーでは、リソースがリクエストで初期データが適切かどうかを明示的に構成できるようにすることをお勧めします。そのような明確な情報がない場合、オリジンサーバーは初期のデータを拒否するか、TLSハンドシェイクの完了前にリクエストが処理されないようにするために、このドキュメントで説明されている手法を実装する必要があります。
A request might be sent partially in early data with the remainder of the request being sent after the handshake completes. This does not necessarily affect handling of that request; what matters is when the server starts acting upon the contents of a request. Any time any server instance might initiate processing prior to completion of the handshake, all server instances need to account for the possibility of replay of early data and how that could affect that processing (see also Section 6.2).
リクエストは部分的に初期データで送信され、残りのリクエストはハンドシェイクの完了後に送信されます。これは必ずしもその要求の処理に影響を与えるわけではありません。重要なのは、サーバーが要求の内容に基づいて動作を開始するときです。サーバーインスタンスがハンドシェイクの完了前に処理を開始する可能性がある場合は常に、すべてのサーバーインスタンスが初期データの再生の可能性とその処理にどのように影響するかを考慮する必要があります（セクション6.2も参照）。
A server can partially process requests that are incomplete. Parsing header fields -- without acting on the values -- and determining request routing is likely to be safe from side effects but other actions might not be.
サーバーは、不完全な要求を部分的に処理できます。値を操作せずにヘッダーフィールドを解析し、リクエストのルーティングを決定することは副作用から安全である可能性が高いですが、他のアクションはそうではない可能性があります。
Intermediary servers do not have sufficient information to decide whether early data can be processed, so Section 5.2 describes a way for the origin to signal to them that a particular request isn't appropriate for early data. Intermediaries that accept early data MUST implement that mechanism.
中間サーバーには、初期データを処理できるかどうかを判断するための十分な情報がないため、セクション5.2では、特定のリクエストが初期データには適切でないことをオリジンがサーバーに通知する方法について説明します。初期のデータを受け入れる仲介者は、そのメカニズムを実装する必要があります。
Note that a server cannot choose to selectively reject early data at the TLS layer. TLS only permits a server to either accept all early data or none of it. Once a server has decided to accept early data, it MUST process all requests in early data, even if the server rejects the request by sending a 425 (Too Early) response.
サーバーは、TLSレイヤーで初期データを選択的に拒否することを選択できないことに注意してください。 TLSは、サーバーがすべての初期データを受け入れるか、どれも受け入れないようにします。サーバーが初期データを受け入れることを決定すると、たとえサーバーが425（Too Early）応答を送信して要求を拒否した場合でも、すべての要求を初期データで処理する必要があります。
A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension. This can be used to avoid committing an arbitrary amount of memory for requests that it might defer until the handshake completes.
サーバーは、「early_data」TLS拡張の「max_early_data_size」フィールドで初期データの量を制限できます。これを使用して、ハンドシェイクが完了するまで延期する可能性のある要求に対して、任意の量のメモリをコミットすることを回避できます。
A client that wishes to use early data commences by sending HTTP requests immediately after sending the TLS ClientHello.
初期のデータを使用したいクライアントは、TLS ClientHelloを送信した直後にHTTPリクエストを送信することから始まります。
By their nature, clients have control over whether a given request is sent in early data, thereby giving the client control over risk of replay. Absent other information, clients MAY send requests with safe HTTP methods ([RFC7231], Section 4.2.1) in early data when it is available and MUST NOT send unsafe methods (or methods whose safety is not known) in early data.
クライアントはその性質上、特定の要求が初期データで送信されるかどうかを制御できるため、クライアントに再生のリスクを制御できます。他の情報がない場合、クライアントは安全なHTTPメソッド（[RFC7231]、セクション4.2.1）を使用できるリクエストを、それが利用可能な場合は早期データで送信できます。また、安全でないメソッド（または安全性が不明なメソッド）を早期データで送信してはなりません。
If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection were new. This could entail using a different negotiated protocol [ALPN] than the one optimistically used for the early data. Any requests sent in early data will need to be sent again, unless the client decides to abandon those requests.
サーバーがTLSレイヤーで初期データを拒否した場合、クライアントは、接続が新しいものであるかのように、再度送信を開始する必要があります。これは、初期のデータに楽観的に使用されたものとは異なるネゴシエートされたプロトコル[ALPN]を使用することを伴う可能性があります。初期のデータで送信された要求は、クライアントがそれらの要求を破棄することを決定しない限り、再度送信する必要があります。
Automatic retry creates the potential for a replay attack. An attacker intercepts a connection that uses early data and copies the early data to another server instance. The second server instance accepts and processes the early data, even though it will not complete the TLS handshake. The attacker then allows the original connection to complete. Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete. If the client then retries requests that were sent in early data, the request will be processed twice.
自動再試行により、リプレイ攻撃の可能性が生じます。攻撃者は、初期データを使用する接続を傍受し、初期データを別のサーバーインスタンスにコピーします。 2番目のサーバーインスタンスは、TLSハンドシェイクを完了しない場合でも、初期データを受け入れて処理します。その後、攻撃者は元の接続の完了を許可します。初期のデータが重複として検出されて拒否された場合でも、最初のサーバーインスタンスが接続の完了を許可する場合があります。その後、クライアントが初期データで送信された要求を再試行すると、要求は2回処理されます。
Replays are also possible if there are multiple server instances that will accept early data or if the same server accepts early data multiple times (though the latter would be in violation of requirements in Section 8 of [TLS13]).
初期データを受け入れるサーバーインスタンスが複数ある場合、または同じサーバーが初期データを複数回受け入れる場合にもリプレイが可能です（後者は[TLS13]のセクション8の要件に違反します）。
Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see Section 5.2.
早期データを使用するクライアントは、425（Too Early）ステータスコードを受信したときにリクエストを再試行する必要があります。セクション5.2を参照してください。
An intermediary MUST NOT use early data when forwarding a request unless early data was used on a previous hop, or it knows that the request can be retried safely without consequences (typically, using out-of-band configuration). Absent better information, that means that an intermediary can only use early data if the request either arrived in early data or arrived with the Early-Data header field set to "1" (see Section 5.1).
仲介者は、前のホップでアーリーデータが使用されていない限り、またはリクエストを結果なしで安全に再試行できることを知っている場合（通常、アウトオブバンド構成を使用）、リクエストを転送するときにアーリーデータを使用してはなりません（MUST NOT）。より良い情報がない場合、つまり、リクエストがアーリーデータで到着したか、Early-Dataヘッダーフィールドが "1"に設定されて到着した場合にのみ、仲介者がアーリーデータを使用できます（セクション5.1を参照）。
Because HTTP requests can span multiple "hops", it is necessary to explicitly communicate whether a request has been sent in early data on a previous hop. Likewise, it is necessary to have some means of explicitly triggering a retry when early data is not desired. Finally, it is necessary to know whether the client will actually perform such a retry.
HTTPリクエストは複数の「ホップ」にまたがることができるため、リクエストが前のホップの初期データで送信されたかどうかを明示的に通信する必要があります。同様に、初期のデータが必要ない場合は、明示的に再試行をトリガーするいくつかの手段が必要です。最後に、クライアントが実際にそのような再試行を実行するかどうかを知る必要があります。
To meet these needs, two signaling mechanisms are defined:
これらのニーズを満たすために、2つのシグナリングメカニズムが定義されています。
o The Early-Data header field is included in requests that might have been forwarded by an intermediary prior to the completion of the TLS handshake with its client.
o Early-Dataヘッダーフィールドは、クライアントとのTLSハンドシェイクの完了前に中間者によって転送された可能性があるリクエストに含まれています。
o The 425 (Too Early) status code is defined for a server to indicate that a request could not be processed due to the consequences of a possible replay attack.
o 425（Too Early）ステータスコードは、可能性のあるリプレイアタックの結果によりリクエストを処理できなかったことをサーバーに示すために定義されています。
They are designed to enable better coordination of the use of early data between the user agent and origin server, and also when a gateway (also "reverse proxy", "Content Delivery Network", or "surrogate") is present.
これらは、ユーザーエージェントとオリジンサーバー間の初期データの使用をより適切に調整できるように設計されており、ゲートウェイ（「リバースプロキシ」、「コンテンツ配信ネットワーク」、または「サロゲート」も）が存在する場合にも使用できます。
Gateways typically don't have specific information about whether a given request can be processed safely when it is sent in early data. In many cases, only the origin server has the necessary information to decide whether the risk of replay is acceptable. These extensions allow coordination between a gateway and its origin server.
通常、ゲートウェイには、特定のリクエストが初期データで送信されたときに安全に処理できるかどうかに関する特定の情報はありません。多くの場合、再生のリスクを許容できるかどうかを判断するために必要な情報を持っているのは、オリジンサーバーだけです。これらの拡張機能により、ゲートウェイとそのオリジンサーバーの間の調整が可能になります。
The Early-Data request header field indicates that the request has been conveyed in early data and that a client understands the 425 (Too Early) status code.
Early-Dataリクエストヘッダーフィールドは、リクエストがアーリーデータで伝達され、クライアントが425（Too Early）ステータスコードを理解していることを示します。
It has just one valid value: "1". Its syntax is defined by the following ABNF [ABNF]:
有効な値は1つだけです：「1」。その構文は、次のABNF [ABNF]によって定義されています。
Early-Data = "1"
For example:
例えば：
GET /resource HTTP/1.0 Host: example.com Early-Data: 1
GET / resource HTTP / 1.0 Host：example.com Early-Data：1
An intermediary that forwards a request prior to the completion of the TLS handshake with its client MUST send it with the Early-Data header field set to "1" (i.e., it adds it if not present in the request). An intermediary MUST use the Early-Data header field if the request might have been subject to a replay and might already have been forwarded by it or another instance (see Section 6.2).
クライアントとのTLSハンドシェイクの完了前にリクエストを転送する仲介者は、Early-Dataヘッダーフィールドを「1」に設定して送信する必要があります（つまり、リクエストに存在しない場合は追加します）。仲介者は、リクエストがリプレイの対象であり、すでにそれまたは別のインスタンスによって転送されている可能性がある場合は、Early-Dataヘッダーフィールドを使用する必要があります（セクション6.2を参照）。
An intermediary MUST NOT remove this header field if it is present in a request. Early-Data MUST NOT appear in a Connection header field.
仲介者は、リクエストに存在する場合、このヘッダーフィールドを削除してはなりません（MUST NOT）。 Early-Dataは、Connectionヘッダーフィールドに表示してはなりません。
The Early-Data header field is not intended for use by user agents (that is, the original initiator of a request). Sending a request in early data implies that the client understands this specification and is willing to retry a request in response to a 425 (Too Early) status code. A user agent that sends a request in early data does not need to include the Early-Data header field.
Early-Dataヘッダーフィールドは、ユーザーエージェント（つまり、要求の元の開始者）による使用を目的としていません。アーリーデータでリクエストを送信することは、クライアントがこの仕様を理解し、425（Too Early）ステータスコードに応答してリクエストを再試行する意思があることを意味します。初期データでリクエストを送信するユーザーエージェントは、Early-Dataヘッダーフィールドを含める必要はありません。
A server cannot make a request that contains the Early-Data header field safe for processing by waiting for the handshake to complete. A request that is marked with Early-Data was sent in early data on a previous hop. Requests that contain the Early-Data header field and cannot be safely processed MUST be rejected using the 425 (Too Early) status code.
サーバーは、ハンドシェイクの完了を待機することにより、処理のために安全なEarly-Dataヘッダーフィールドを含む要求を行うことができません。 Early-Dataでマークされた要求は、前のホップの早期データで送信されました。 Early-Dataヘッダーフィールドを含み、安全に処理できないリクエストは、425（Too Early）ステータスコードを使用して拒否する必要があります。
The Early-Data header field carries a single bit of information, and clients MUST include at most one instance. Multiple or invalid instances of the header field MUST be treated as equivalent to a single instance with a value of 1 by a server.
Early-Dataヘッダーフィールドには1ビットの情報が含まれ、クライアントは最大で1つのインスタンスを含める必要があります。ヘッダーフィールドの複数のインスタンスまたは無効なインスタンスは、サーバーによって値が1の単一のインスタンスと同等として扱われる必要があります。
An Early-Data header field MUST NOT be included in responses or request trailers.
Early-Dataヘッダーフィールドは、応答または要求のトレーラーに含めてはなりません（MUST NOT）。
A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed.
425（早すぎる）ステータスコードは、サーバーが、再生される可能性のある要求を処理するリスクを負わないことを示します。
User agents that send a request in early data are expected to retry the request when receiving a 425 (Too Early) response status code. A user agent SHOULD retry automatically, but any retries MUST NOT be sent in early data.
アーリーデータでリクエストを送信するユーザーエージェントは、425（Too Early）レスポンスステータスコードを受け取ったときにリクエストを再試行することが期待されています。ユーザーエージェントは自動的に再試行する必要があります（SHOULD）が、再試行は初期のデータで送信してはなりません（MUST NOT）。
In all cases, an intermediary can forward a 425 (Too Early) status code. Intermediaries MUST forward a 425 (Too Early) status code if the request that it received and forwarded contained an Early-Data header field. Otherwise, an intermediary that receives a request in early data MAY automatically retry that request in response to a 425 (Too Early) status code, but it MUST wait for the TLS handshake to complete on the connection where it received the request.
すべての場合において、仲介者は425（早すぎる）ステータスコードを転送できます。仲介者は、受信して転送したリクエストにEarly-Dataヘッダーフィールドが含まれていた場合、425（Too Early）ステータスコードを転送する必要があります。それ以外の場合、アーリーデータでリクエストを受け取った仲介者は、425（Too Early）ステータスコードに応じてそのリクエストを自動的に再試行してもかまいませんが、リクエストを受け取った接続でTLSハンドシェイクが完了するのを待つ必要があります。
The server cannot assume that a client is able to retry a request unless the request is received in early data or the Early-Data header field is set to "1". A server SHOULD NOT emit the 425 status code unless one of these conditions is met.
サーバーは、リクエストがアーリーデータで受信されるか、Early-Dataヘッダーフィールドが「1」に設定されていない限り、クライアントがリクエストを再試行できるとは想定できません。これらの条件のいずれかが満たされない限り、サーバーは425ステータスコードを発行しないでください。
The 425 (Too Early) status code is not cacheable by default. Its payload is not the representation of any identified resource.
425（Too Early）ステータスコードは、デフォルトではキャッシュできません。そのペイロードは、識別されたリソースの表現ではありません。
Using early data exposes a client to the risk that their request is replayed. A retried or replayed request can produce different side effects on the server. In addition to those side effects, replays and retries might be used for traffic analysis to recover information about requests or the resources those requests target. In particular, a request that is replayed might result in a different response, which might be observable from the length of protected data even if the content remains confidential.
初期のデータを使用すると、クライアントはリクエストが再生されるリスクにさらされます。再試行または再生された要求は、サーバーにさまざまな副作用を引き起こす可能性があります。これらの副作用に加えて、リプレイとリトライは、リクエストまたはそれらのリクエストがターゲットとするリソースに関する情報を回復するためのトラフィック分析に使用される場合があります。特に、要求が再生されると、応答が異なる場合があります。これは、コンテンツが機密のままである場合でも、保護されたデータの長さから観察できる場合があります。
A gateway MUST NOT forward requests that were received in early data unless it knows that the origin server it will forward to understands the Early-Data header field and will correctly generate a 425 (Too Early) status code. A gateway that is uncertain about origin server support for a given request SHOULD either delay forwarding the request until the TLS handshake with its client completes or send a 425 (Too Early) status code in response.
ゲートウェイは、転送するオリジンサーバーがEarly-Dataヘッダーフィールドを理解し、425（Too Early）ステータスコードを正しく生成することを知らない限り、アーリーデータで受信したリクエストを転送してはなりません（MUST NOT）。特定のリクエストに対するオリジンサーバーのサポートが不明確なゲートウェイは、クライアントとのTLSハンドシェイクが完了するまでリクエストの転送を遅らせるか、または応答として425（Too Early）ステータスコードを送信する必要があります。
A gateway without at least one potential origin server that supports the Early-Data header field expends significant effort for what can at best be a modest performance benefit from enabling early data. If no origin server supports early data, it is more efficient to disable early data entirely.
Early-Dataヘッダーフィールドをサポートする潜在的なオリジンサーバーが1つもないゲートウェイは、初期データを有効にすることによるパフォーマンスの向上に少しでも貢献できるように多大な労力を費やします。初期データをサポートするオリジンサーバーがない場合は、初期データを完全に無効にする方が効率的です。
Consistent treatment of a request that arrives in, or partially in, early data is critical to avoiding inappropriate processing of replayed requests. If a request is not safe to process before the TLS handshake completes, then all instances of the server (including gateways) need to agree and either reject the request or delay processing.
再生されたリクエストの不適切な処理を回避するには、初期データに到着した、または部分的に到着したリクエストを一貫して処理することが重要です。 TLSハンドシェイクが完了する前にリクエストを処理しても安全でない場合は、サーバーのすべてのインスタンス（ゲートウェイを含む）が同意して、リクエストを拒否するか、処理を遅延させる必要があります。
Disabling early data, delaying requests, or rejecting requests with the 425 (Too Early) status code are all equally good measures for mitigating replay attacks on requests that might be vulnerable to replay. Server instances can implement any of these measures and be considered consistent, even if different instances use different methods. Critically, this means that it is possible to employ different mitigations in reaction to other conditions, such as server load.
早期データの無効化、リクエストの遅延、425（Too Early）ステータスコードによるリクエストの拒否は、すべて、リプレイに対して脆弱である可能性のあるリクエストに対するリプレイ攻撃を軽減するための同等の優れた手段です。サーバーインスタンスは、これらの手段のいずれかを実装でき、異なるインスタンスが異なる方法を使用していても、整合性があると見なされます。批判的には、これは、サーバーの負荷などの他の条件に応じて異なる緩和策を採用することが可能であることを意味します。
A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data.
サーバーと他のサーバーインスタンスが同じデータを処理する方法について異なる決定を下せる場合、サーバーはハンドシェイクが完了する前に初期データに基づいて動作してはなりません（MUST NOT）。
Accepting early data exposes a server to potential denial of service through the replay of requests that are expensive to handle. A server that is under load SHOULD prefer rejecting TLS early data as a whole rather than accepting early data and selectively processing requests. Generating a 503 (Service Unavailable) or 425 (Too Early) status code often leads to clients retrying requests, which could result in increased load.
初期のデータを受け入れると、処理にコストがかかる要求の再生を通じて、サーバーがサービス拒否の可能性にさらされます。負荷がかかっているサーバーは、初期データを受け入れてリクエストを選択的に処理するのではなく、TLS初期データ全体を拒否することを推奨します。 503（Service Unavailable）または425（Too Early）ステータスコードを生成すると、多くの場合、クライアントがリクエストを再試行することになり、負荷が増大する可能性があります。
In protocols that deliver data out of order (such as QUIC [HQ]), early data can arrive after the handshake completes. A server MAY process requests received in early data after handshake completion only if it can rely on other instances correctly handling replays of the same requests.
順不同でデータを配信するプロトコル（QUIC [HQ]など）では、ハンドシェイクの完了後に早期のデータが到着する可能性があります。サーバーは、同じリクエストのリプレイを正しく処理する他のインスタンスに依存できる場合にのみ、ハンドシェイクの完了後に初期データで受信されたリクエストを処理できます。
This document registers the Early-Data header field in the "Permanent Message Header Field Names" registry located at <https://www.iana.org/assignments/message-headers>.
このドキュメントでは、<https://www.iana.org/assignments/message-headers>にある「Permanent Message Header Field Names」レジストリのEarly-Dataヘッダーフィールドを登録します。
Header field name: Early-Data
ヘッダーフィールド名：Early-Data
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
作成者/変更コントローラ：IETF
Specification document(s): This document
仕様書：この文書
Related information: (empty)
関連情報：（空）
This document registers the 425 (Too Early) status code in the "HTTP Status Codes" registry located at <https://www.iana.org/assignments/ http-status-codes>.
このドキュメントは、<https://www.iana.org/assignments/http-status-codes>にある「HTTPステータスコード」レジストリに425（早すぎる）ステータスコードを登録します。
Value: 425
値：425
Description: Too Early
説明：早すぎます
Reference: This document
参照：このドキュメント
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[ABNF]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[HTTP]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[TLS13] Rescorla、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[ALPN] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、< https://www.rfc-editor.org/info/rfc7301>。
[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over QUIC", Work in Progress, draft-ietf-quic-http-14, August 2018.
[HQ] Bishop、M。、「Hypertext Transfer Protocol（HTTP）over QUIC」、Work in Progress、draft-ietf-quic-http-14、2018年8月。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：// www.rfc-editor.org/info/rfc7540>。
Acknowledgments
謝辞
This document was not easy to produce. The following people made substantial contributions to the quality and completeness of the document: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev.
この文書は簡単に作成できませんでした。次の人々は、ドキュメントの品質と完全性に多大な貢献をしました：David Benjamin、Subodh Iyengar、Benjamin Kaduk、Ilari Liusavaara、Kazuho Oku、Eric Rescorla、Kyle Rose、Victor Vasiliev。
Authors' Addresses
著者のアドレス
Martin Thomson Mozilla
マーティン・トムソン・モジラ
Email: martin.thomson@gmail.com
Mark Nottingham Fastly
マークノッティンガムFastly
Email: mnot@mnot.net
Willy Tarreau HAProxy Technologies
ウィリータローHAProxyテクノロジー
Email: willy@haproxy.org