draft-ietf-httpbis-replay-03.txt   draft-ietf-httpbis-replay-04.txt 
HTTP M. Thomson HTTP M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track M. Nottingham Intended status: Standards Track M. Nottingham
Expires: November 4, 2018 Fastly Expires: December 29, 2018 Fastly
W. Tarreau W. Tarreau
HAProxy Technologies HAProxy Technologies
May 03, 2018 June 27, 2018
Using Early Data in HTTP Using Early Data in HTTP
draft-ietf-httpbis-replay-03 draft-ietf-httpbis-replay-04
Abstract Abstract
Using TLS early data creates an exposure to the possibility of a Using TLS early data creates an exposure to the possibility of a
replay attack. This document defines mechanisms that allow clients replay attack. This document defines mechanisms that allow clients
to communicate with servers about HTTP requests that are sent in to communicate with servers about HTTP requests that are sent in
early data. Techniques are described that use these mechanisms to early data. Techniques are described that use these mechanisms to
mitigate the risk of replay. mitigate the risk of replay.
Note to Readers Note to Readers
RFC Editor: Please remove this section before publication.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
Working Group information can be found at http://httpwg.github.io/ Working Group information can be found at http://httpwg.github.io/
[2]; source code and issues list for this draft can be found at [2]; source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/replay [3]. https://github.com/httpwg/http-extensions/labels/replay [3].
Status of This Memo Status of This Memo
skipping to change at page 1, line 47 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2018. This Internet-Draft will expire on December 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Early Data in HTTP . . . . . . . . . . . . . . . . . . . . . 3 2. Early Data in HTTP . . . . . . . . . . . . . . . . . . . . . 3
3. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3 3. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3
4. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 5 4. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 5
5. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 6 5. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 6
5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 7 5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 7
5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 8 5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 8 6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 9
6.2. Consistent Handling of Early Data . . . . . . . . . . . . 9 6.2. Consistent Handling of Early Data . . . . . . . . . . . . 9
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9
6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9 6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
TLS 1.3 [TLS13] introduces the concept of early data (also known as TLS 1.3 [TLS13] introduces the concept of early data (also known as
zero round trip data or 0-RTT data). Early data allows a client to zero round trip data or 0-RTT data). Early data allows a client to
send data to a server in the first round trip of a connection, send data to a server in the first round trip of a connection,
without waiting for the TLS handshake to complete if the client has without waiting for the TLS handshake to complete, if the client has
spoken to the same server recently. spoken to the same server recently.
When used with HTTP [HTTP], early data allows clients to send When used with HTTP [HTTP], early data allows clients to send
requests immediately, avoiding the one or two round trip delay needed requests immediately, avoiding the one or two round trip delay needed
for the TLS handshake. This is a significant performance for the TLS handshake. This is a significant performance
enhancement; however, it has significant limitations. enhancement; however, it has significant limitations.
The primary risk of using early data is that an attacker might The primary risk of using early data is that an attacker might
capture and replay the request(s) it contains. TLS [TLS13] describes capture and replay the request(s) it contains. TLS [TLS13] describes
techniques that can be used to reduce the likelihood that an attacker techniques that can be used to reduce the likelihood that an attacker
skipping to change at page 4, line 5 skipping to change at page 4, line 5
completes, the early data received on that TLS connection is known to 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 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 note that this does not mean that early data will not be or has not
been replayed on another connection. been replayed on another connection.
3. Supporting Early Data in HTTP Servers 3. Supporting Early Data in HTTP Servers
A server decides whether or not to offer a client the ability to send 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. early data on future connections when sending the TLS session ticket.
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.
When a server enables early data, there are a number of techniques it When a server enables early data, there are a number of techniques it
can use to mitigate the risks of replay: can use to mitigate the risks of replay:
1. TLS [TLS13] mandates the use of replay detection strategies that 1. The server can reject early data at the TLS layer. A server
reduce the ability of an attacker to successfully replay early cannot selectively reject early data, so this results in all
data. These anti-replay techniques reduce but don't completely requests sent in early data being discarded.
eliminate the chance of data being replayed and ensure a fixed
upper limit to the number of replays.
2. The server can reject early data. A server cannot selectively
reject early data, so this results in all requests sent in early
data being discarded.
3. The server can choose to delay processing of early data until 2. The server can choose to delay processing of early data until
after the TLS handshake completes. By deferring processing, it after the TLS handshake completes. By deferring processing, it
can ensure that only a successfully completed connection is used can ensure that only a successfully completed connection is used
for the request(s) therein. This provides the server with some for the request(s) therein. This provides the server with some
assurance that the early data was not replayed. 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.
4. If the server receives multiple requests in early data, it can 3. The server can cause a client to retry individual requests and
determine whether to defer HTTP processing on a per-request not use early data by responding with the 425 (Too Early) status
basis. code (Section 5.2), in cases where the risk of replay is judged
too great.
5. The server can cause a client to retry a request and not use Any of these techniques is equally effective and a server can use the
early data by responding with the 425 (Too Early) status code method that best suits it.
(Section 5.2), in cases where the risk of replay is judged too
great.
For a given request, the level of tolerance to replay risk is For a given request, the level of tolerance to replay risk is
specific to the resource it operates upon (and therefore only known specific to the resource it operates upon (and therefore only known
to the origin server). In general, if processing a request does not to the origin server). The primary risk associated with using early
have state-changing side effects, the consequences of replay are not data is in the actions a server takes when processing a request;
significant. 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.
The request method's safety ([RFC7231], Section 4.2.1) is one way to The request method's safety ([RFC7231], Section 4.2.1) is one way to
determine this. However, some resources do elect to associate side determine this. However, some resources do produce side effects with
effects with safe methods, so this cannot be universally relied upon. safe methods, so this cannot be universally relied upon.
It is RECOMMENDED that origin servers allow resources to explicitly It is RECOMMENDED that origin servers allow resources to explicitly
configure whether early data is appropriate in requests. Absent such configure whether early data is appropriate in requests. Absent such
explicit information, origin servers MUST either reject early data or explicit information, origin servers MUST either reject early data or
implement the techniques described in this document for ensuring that implement the techniques described in this document for ensuring that
requests are not processed prior to TLS handshake completion. requests are not processed prior to TLS handshake completion.
A request might be sent partially in early data with the remainder of A request might be sent partially in early data with the remainder of
the request being sent after the handshake completes. This does not the request being sent after the handshake completes. This does not
necessarily affect handling of that request; what matters is when the necessarily affect handling of that request; what matters is when the
server starts acting upon the contents of a request. Any time any server starts acting upon the contents of a request. Any time any
server instance might initiate processing prior to completion of the server instance might initiate processing prior to completion of the
handshake, all server instances need to consider how a possible handshake, all server instances need to account for the possibility
replay of early data could affect that processing (see also of replay of early data and how that could affect that processing
Section 6.2). (see also Section 6.2).
A server can partially process requests that are incomplete. Parsing A server can partially process requests that are incomplete. Parsing
header fields - without acting on the values - and determining header fields - without acting on the values - and determining
request routing is likely to be safe from side-effects, but other request routing is likely to be safe from side-effects, but other
actions might not be. actions might not be.
Intermediary servers do not have sufficient information to make this Intermediary servers do not have sufficient information to decide
determination, so Section 5.2 describes a way for the origin to whether early data can be processed, so Section 5.2 describes a way
signal to them that a particular request isn't appropriate for early for the origin to signal to them that a particular request isn't
data. Intermediaries that accept early data MUST implement that appropriate for early data. Intermediaries that accept early data
mechanism. MUST implement that mechanism.
Note that a server cannot choose to selectively reject early data at Note that a server cannot choose to selectively reject early data at
the TLS layer. TLS only permits a server to accept all early data, the TLS layer. TLS only permits a server to accept all early data,
or none of it. Once a server has decided to accept early data, it 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 MUST process all requests in early data, even if the server rejects
the request by sending a 425 (Too Early) response. the request by sending a 425 (Too Early) response.
A server can limit the amount of early data with the A server can limit the amount of early data with the
"max_early_data_size" field of the "early_data" TLS extension. This "max_early_data_size" field of the "early_data" TLS extension. This
can be used to avoid committing an arbitrary amount of memory for can be used to avoid committing an arbitrary amount of memory for
deferred requests. A server SHOULD ensure that when it accepts early requests that it might defer until the handshake completes.
data, it can defer processing of requests until after the TLS
handshake completes.
4. Using Early Data in HTTP Clients 4. Using Early Data in HTTP Clients
A client that wishes to use early data commences sending HTTP A client that wishes to use early data commences sending HTTP
requests immediately after sending the TLS ClientHello. requests immediately after sending the TLS ClientHello.
By their nature, clients have control over whether a given request is By their nature, clients have control over whether a given request is
sent in early data - thereby giving the client control over risk of sent in early data - thereby giving the client control over risk of
replay. Absent other information, clients MAY send requests with replay. Absent other information, clients MAY send requests with
safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when
it is available, and SHOULD NOT send unsafe methods (or methods whose it is available, and MUST NOT send unsafe methods (or methods whose
safety is not known) in early data. safety is not known) in early data.
If the server rejects early data at the TLS layer, a client MUST If the server rejects early data at the TLS layer, a client MUST
start sending again as though the connection was new. This could start sending again as though the connection were new. This could
entail using a different negotiated protocol [ALPN] than the one entail using a different negotiated protocol [ALPN] than the one
optimistically used for the early data. Any requests sent in early optimistically used for the early data. Any requests sent in early
data MUST be sent again, unless the client decides to abandon those data will need to be sent again, unless the client decides to abandon
requests. those requests.
Automatic retry creates the potential for a replay attack. An Automatic retry creates the potential for a replay attack. An
attacker intercepts a connection that uses early data and copies the attacker intercepts a connection that uses early data and copies the
early data to another server instance. The second server instance early data to another server instance. The second server instance
accepts and processes the early data. The attacker then allows the accepts and processes the early data, even though it will not
original connection to complete. Even if the early data is detected complete the TLS handshake. The attacker then allows the original
as a duplicate and rejected, the first server instance might allow connection to complete. Even if the early data is detected as a
the connection to complete. If the client then retries requests that 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. were sent in early data, the request will be processed twice.
Replays are also possible if there are multiple server instances that Replays are also possible if there are multiple server instances that
will accept early data, or if the same server accepts early data will accept early data, or if the same server accepts early data
multiple times (though this would be in violation of requirements in multiple times (though the latter would be in violation of
Section 8 of [TLS13]). requirements in Section 8 of [TLS13]).
Clients that use early data MUST retry requests upon receipt of a 425 Clients that use early data MUST retry requests upon receipt of a 425
(Too Early) status code; see Section 5.2. (Too Early) status code; see Section 5.2.
An intermediary MUST NOT use early data when forwarding a request 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 unless early data was used on a previous hop, or it knows that the
request can be retried safely without consequences (typically, using request can be retried safely without consequences (typically, using
out-of-band configuration). Absent better information, that means out-of-band configuration). Absent better information, that means
that an intermediary can only use early data if the request either that an intermediary can only use early data if the request either
arrived in early data or arrived with the "Early-Data" header field arrived in early data or arrived with the "Early-Data" header field
set to "1" (see Section 5.1). set to "1" (see Section 5.1).
5. Extensions for Early Data in HTTP 5. Extensions for Early Data in HTTP
Because HTTP requests can span multiple "hops", it is necessary to Because HTTP requests can span multiple "hops", it is necessary to
explicitly communicate whether a request has been sent in early data explicitly communicate whether a request has been sent in early data
on a previous connection. Likewise, some means of explicitly on a previous hop. Likewise, some means of explicitly triggering a
triggering a retry when early data is not desirable is necessary. retry when early data is not desirable is necessary. Finally, it is
Finally, it is necessary to know whether the client will actually necessary to know whether the client will actually perform such a
perform such a retry. retry.
To meet these needs, two signalling mechanisms are defined: To meet these needs, two signalling mechanisms are defined:
o The "Early-Data" header field is included in requests that might o The "Early-Data" header field is included in requests that might
have been forwarded by an intermediary prior to the TLS handshake have been forwarded by an intermediary prior to the TLS handshake
with its client completing. with its client completing.
o The 425 (Too Early) status code is defined for a server to o The 425 (Too Early) status code is defined for a server to
indicate that a request could not be processed due to the indicate that a request could not be processed due to the
consequences of a possible replay attack. consequences of a possible replay attack.
skipping to change at page 7, line 32 skipping to change at page 7, line 37
For example: For example:
GET /resource HTTP/1.0 GET /resource HTTP/1.0
Host: example.com Host: example.com
Early-Data: 1 Early-Data: 1
An intermediary that forwards a request prior to the completion of An intermediary that forwards a request prior to the completion of
the TLS handshake with its client MUST send it with the "Early-Data" 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 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 request). An intermediary MUST use the "Early-Data" header field if
it might have forwarded the request prior to handshake completion it - or another instance (see Section 6.2) - could have forwarded the
(see Section 6.2 for details). request prior to handshake completion if circumstances were
different.
An intermediary MUST NOT remove this header field if it is present in An intermediary MUST NOT remove this header field if it is present in
a request. "Early-Data" MUST NOT appear in a "Connection" header a request. "Early-Data" MUST NOT appear in a "Connection" header
field. field.
The "Early-Data" header field is not intended for use by user agents 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 (that is, the original initiator of a request). Sending a request in
early data implies that the client understands this specification and early data implies that the client understands this specification and
is willing to retry a request in response to a 425 (Too Early) status 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 code. A user agent that sends a request in early data does not need
to include the "Early-Data" header field. to include the "Early-Data" header field.
A server cannot make a request that contains the Early-Data header A server cannot make a request that contains the Early-Data header
field safe for processing by waiting for the handshake to complete. 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 A request that is marked with Early-Data was sent in early data on a
previous hop. Requests that contain the Early-Data field and cannot previous hop. Requests that contain the Early-Data field and cannot
be safely processed MUST be rejected using the 425 (Too Early) status be safely processed MUST be rejected using the 425 (Too Early) status
code. code.
The "Early-Data" header field carries a single bit of information and The "Early-Data" header field carries a single bit of information and
clients MUST include at most one instance. Multiple instances MUST clients MUST include at most one instance. Multiple or invalid
be treated as equivalent to a single instance by a server. instances of the header field MUST be treated as equivalent to a
single instance with a value of 1 by a server.
A "Early-Data" header field MUST NOT be included in responses or A "Early-Data" header field MUST NOT be included in responses or
request trailers. request trailers.
5.2. The 425 (Too Early) Status Code 5.2. The 425 (Too Early) Status Code
A 425 (Too Early) status code indicates that the server is unwilling A 425 (Too Early) status code indicates that the server is unwilling
to risk processing a request that might be replayed. to risk processing a request that might be replayed.
User agents that send a request in early data MUST automatically User agents that send a request in early data are expected to retry
retry the request when receiving a 425 (Too Early) response status the request when receiving a 425 (Too Early) response status code. A
code. Such retries MUST NOT be sent in early data. user agent MAY do so automatically, but any retries MUST NOT be sent
in early data.
In all cases, an intermediary can forward a 425 (Too Early) status In all cases, an intermediary can forward a 425 (Too Early) status
code. Intermediaries MUST forward a 425 (Too Early) status code if code. Intermediaries MUST forward a 425 (Too Early) status code if
the request that it received and forwarded contained an "Early-Data" the request that it received and forwarded contained an "Early-Data"
header field. Otherwise, an intermediary that receives a request in header field. Otherwise, an intermediary that receives a request in
early data MAY automatically retry that request in response to a 425 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 (Too Early) status code, but it MUST wait for the TLS handshake to
complete on the connection where it received the request. complete on the connection where it received the request.
The server cannot assume that a client is able to retry a request The server cannot assume that a client is able to retry a request
skipping to change at page 8, line 43 skipping to change at page 8, line 52
The 425 (Too Early) status code is not cacheable by default. Its The 425 (Too Early) status code is not cacheable by default. Its
payload is not the representation of any identified resource. payload is not the representation of any identified resource.
6. Security Considerations 6. Security Considerations
Using early data exposes a client to the risk that their request is Using early data exposes a client to the risk that their request is
replayed. A retried or replayed request can produce different side replayed. A retried or replayed request can produce different side
effects on the server. In addition to those side effects, replays effects on the server. In addition to those side effects, replays
and retries might be used for traffic analysis to recover information and retries might be used for traffic analysis to recover information
about requests or the resources those requests target. 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.
6.1. Gateways and Early Data 6.1. Gateways and Early Data
A gateway that forwards requests that were received in early data A gateway MUST NOT forward requests that were received in early data
MUST only do so if it knows that the origin server that receives unless it knows that the origin server it will forward to understands
those requests understands the "Early-Data" header field and will the "Early-Data" header field and will correctly generate a 425 (Too
correctly generate a 425 (Too Early) status code. A gateway that is Early) status code. A gateway that is uncertain about origin server
uncertain about origin server support for a given request SHOULD support for a given request SHOULD either delay forwarding the
either delay forwarding the request until the TLS handshake with its request until the TLS handshake with its client completes, or send a
client completes, or send a 425 (Too Early) status code in response. 425 (Too Early) status code in response.
A gateway without at least one potential origin server that supports A gateway without at least one potential origin server that supports
"Early-Data" header field expends significant effort for what can at "Early-Data" header field expends significant effort for what can at
best be a modest performance benefit from enabling early data. If no best be a modest performance benefit from enabling early data. If no
origin server supports early data, disabling early data entirely is origin server supports early data, disabling early data entirely is
more efficient. more efficient.
6.2. Consistent Handling of Early Data 6.2. Consistent Handling of Early Data
Consistent treatment of a request that arrives in - or partially in - Consistent treatment of a request that arrives in - or partially in -
skipping to change at page 9, line 49 skipping to change at page 10, line 12
server that is under load SHOULD prefer rejecting TLS early data as a server that is under load SHOULD prefer rejecting TLS early data as a
whole rather than accepting early data and selectively processing whole rather than accepting early data and selectively processing
requests. Generating a 503 (Service Unavailable) or 425 (Too Early) requests. Generating a 503 (Service Unavailable) or 425 (Too Early)
status code often leads to clients retrying requests, which could status code often leads to clients retrying requests, which could
result in increased load. result in increased load.
6.4. Out of Order Delivery 6.4. Out of Order Delivery
In protocols that deliver data out of order (such as QUIC [HQ]) 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 data can arrive after the handshake completes. A server MAY process
requests received in early data after handshake completion if it can requests received in early data after handshake completion only if it
rely on other instances correctly handling replays of the same can rely on other instances correctly handling replays of the same
requests. requests.
7. IANA Considerations 7. IANA Considerations
This document registers the "Early-Data" header field in the "Message This document registers the "Early-Data" header field in the "Message
Headers" registry located at https://www.iana.org/assignments/ Headers" registry located at https://www.iana.org/assignments/
message-headers [4]. message-headers [4].
Header field name: Early-Data Header field name: Early-Data
skipping to change at page 10, line 24 skipping to change at page 10, line 35
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): This document Specification document(s): This document
Related information: (empty) Related information: (empty)
This document registers the 425 (Too Early) status code in the This document registers the 425 (Too Early) status code in the
"Hypertext Transfer Protocol (HTTP) Status Code" registry established "Hypertext Transfer Protocol (HTTP) Status Code" registry located at
in [RFC7231]. https://www.iana.org/assignments/http-status-codes [5].
Value: 425 Value: 425
Description: Too Early Description: Too Early
Reference: This document Reference: This document
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 11, line 44 skipping to change at page 12, line 5
8.3. URIs 8.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/ [2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/replay [3] https://github.com/httpwg/http-extensions/labels/replay
[4] https://www.iana.org/assignments/message-headers [4] https://www.iana.org/assignments/message-headers
[5] https://www.iana.org/assignments/http-status-codes
Acknowledgments Acknowledgments
This document was not easy to produce. The following people made This document was not easy to produce. The following people made
substantial contributions to the quality and completeness of the substantial contributions to the quality and completeness of the
document: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari document: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari
Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and Victor Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and Victor
Vasiliev. Vasiliev.
Authors' Addresses Authors' Addresses
 End of changes. 34 change blocks. 
75 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/