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
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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握手所需的一到两次往返延迟。这是一个显著的性能提升；然而，它有很大的局限性。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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（太早）状态代码（第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节）是确定这一点的一种方法。然而，一些资源使用安全的方法会产生副作用，因此不能普遍依赖。
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（太早）响应拒绝请求。
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.
服务器可以使用“早期数据”TLS扩展的“最大早期数据大小”字段限制早期数据量。这可以用来避免为可能延迟到握手完成的请求提交任意数量的内存。
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.
自动重试可能造成重播攻击。攻击者拦截使用早期数据的连接，并将早期数据复制到另一个服务器实例。第二个服务器实例接受并处理早期数据，即使它不会完成TLS握手。然后，攻击者允许原始连接完成。即使早期数据被检测为重复数据并被拒绝，第一个服务器实例也可能允许连接完成。如果客户端然后重试在早期数据中发送的请求，则该请求将被处理两次。
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（太早）状态代码后重试请求；见第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).
中间层在转发请求时不得使用早期数据，除非在前一个跃点上使用了早期数据，或者它知道可以安全地重试请求而不会产生任何后果（通常，使用带外配置）。如果没有更好的信息，这意味着只有在请求以早期数据的形式到达或者到达时早期数据头字段设置为“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:
为了满足这些需求，定义了两种信号机制：
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 “早期数据头”字段包含在可能在完成与客户机的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（太早）状态代码是为服务器定义的，用于指示由于可能的重播攻击的后果而无法处理请求。
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.
早期数据请求报头字段指示请求已在早期数据中传送，并且客户端理解425（太早）状态代码。
It has just one valid value: "1". Its syntax is defined by the following ABNF [ABNF]:
它只有一个有效值：“1”。其语法由以下ABNF[ABNF]定义：
Early-Data = "1"
Early-Data = "1"
For example:
例如：
GET /resource HTTP/1.0 Host: example.com Early-Data: 1
GET/resource HTTP/1.0主机：example.com早期数据：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握手之前转发请求的中介必须在发送请求时将“早期数据头”字段设置为“1”（即，如果请求中不存在，则添加请求）。如果请求可能受到重播的影响，并且可能已经由它或另一个实例转发，则中介必须使用“早期数据头”字段（请参见第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.
如果请求中存在此标头字段，则中间层不得删除该字段。早期数据不得出现在连接头字段中。
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.
早期数据头字段不供用户代理（即请求的原始发起人）使用。在早期数据中发送请求意味着客户端理解此规范，并且愿意重试请求以响应425（太早）状态代码。在早期数据中发送请求的用户代理不需要包含早期数据头字段。
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.
服务器无法通过等待握手完成来发出包含早期数据头字段的请求，以便安全处理。标记为早期数据的请求在前一个跃点的早期数据中发送。必须使用425（太早）状态代码拒绝包含早期数据标头字段且无法安全处理的请求。
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.
“早期数据头”字段携带单个信息位，客户端最多必须包含一个实例。服务器必须将标头字段的多个或无效实例视为等同于值为1的单个实例。
An Early-Data header field MUST NOT be included in responses or request trailers.
响应或请求跟踪中不得包含早期数据头字段。
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（太早）响应状态代码时将重试该请求。用户代理应自动重试，但不得在早期数据中发送任何重试。
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（太早）状态代码。如果中介机构接收和转发的请求包含早期数据头字段，则中介机构必须转发425（太早）状态代码。否则，在早期数据中接收请求的中介可以响应425（太早）状态码自动重试该请求，但它必须等待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.
服务器无法假定客户端能够重试请求，除非在早期数据中收到请求，或者早期数据头字段设置为“1”。除非满足以下条件之一，否则服务器不应发出425状态代码。
The 425 (Too Early) status code is not cacheable by default. Its payload is not the representation of any identified resource.
默认情况下，425（太早）状态代码不可缓存。其有效载荷不是任何已识别资源的表示。
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
网关不得转发在早期数据中接收的请求，除非它知道它将转发的原始服务器了解早期数据头字段，并且将正确生成425（太早）状态代码。不确定源服务器是否支持给定请求的网关应延迟转发请求
request until the TLS handshake with its client completes or send a 425 (Too Early) status code in response.
请求，直到TLS与其客户端的握手完成，或者发送425（太早）状态代码作为响应。
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.
如果网关没有至少一个支持早期数据头字段的潜在源服务器，那么它将花费大量精力来实现启用早期数据最多只能带来适度的性能好处。如果没有原始服务器支持早期数据，则完全禁用早期数据更有效。
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（太早）的请求都是缓解对可能易受重播攻击的请求的重播攻击的良好措施。即使不同的实例使用不同的方法，服务器实例也可以实现这些度量中的任何一个，并且被认为是一致的。关键的是，这意味着可以对其他条件（如服务器负载）采用不同的缓解措施。
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.
如果服务器和任何其他服务器实例可能对如何处理相同数据做出不同的决定，则在握手完成之前，服务器不得对早期数据进行操作。
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（服务不可用）或425（太早）状态代码通常会导致客户端重试请求，这可能会导致负载增加。
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>.
Header field name: 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>.
本文档在位于的“HTTP状态代码”注册表中注册425（太早）状态代码<https://www.iana.org/assignments/ http状态代码>。
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]Crocker，D.，Ed.和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]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，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]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年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，“传输层安全（TLS）应用层协议协商扩展”，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.，“QUIC上的超文本传输协议（HTTP）”，正在进行的工作，草稿-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.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本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.
这份文件不容易制作。以下人员对文件的质量和完整性做出了重大贡献：大卫·本杰明、苏博德·伊扬格、本杰明·卡杜克、伊拉里·柳萨瓦拉、卡祖霍·奥库、埃里克·雷斯科拉、凯尔·罗斯和维克托·瓦西里耶夫。
Authors' Addresses
作者地址
Martin Thomson Mozilla
马丁·汤姆森·莫齐拉
Email: martin.thomson@gmail.com
Email: martin.thomson@gmail.com
Mark Nottingham Fastly
马克·诺丁汉·法斯特利
Email: mnot@mnot.net
Email: mnot@mnot.net
Willy Tarreau HAProxy Technologies
威利·塔瑞欧HAProxy技术公司
Email: willy@haproxy.org
Email: willy@haproxy.org