draft-ietf-httpbis-replay-04.txt		draft-ietf-httpbis-replay-latest.txt
	HTTP Working Group M. Thomson		HTTP Working Group M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track M. Nottingham		Intended status: Standards Track M. Nottingham
	Expires: December 29, 2018 Fastly		Expires: April 29, 2023 Fastly
	W. Tarreau		W. Tarreau
	HAProxy Technologies		HAProxy Technologies
	June 27, 2018		October 26, 2022
	Using Early Data in HTTP		Using Early Data in HTTP
	draft-ietf-httpbis-replay-04		draft-ietf-httpbis-replay-latest
	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
	skipping to change at page 1, line 49 ¶		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 December 29, 2018.		This Internet-Draft will expire on April 29, 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	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 . . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . . . . . . . . . . . . . . . 12		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 time (0-RTT) data). If the client has spoken to the
	send data to a server in the first round trip of a connection,		same server recently, early data allows a client to send data to a
	without waiting for the TLS handshake to complete, if the client has		server in the first round trip of a connection, without waiting for
	spoken to the same server recently.		the TLS handshake to complete.
	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, thus avoiding the one or two round-trip delays
	for the TLS handshake. This is a significant performance		needed 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
	can successfully replay a request, but these techniques can be		can successfully replay a request, but these techniques can be
	difficult to deploy, and still leave some possibility of a successful		difficult to deploy and still leave some possibility of a successful
	attack.		attack.
	Note that this is different from automated or user-initiated retries;		Note that this is different from automated or user-initiated retries;
	replays are initiated by an attacker without the awareness of the		replays are initiated by an attacker without the awareness of the
	client.		client.
	To help mitigate the risk of replays in HTTP, this document gives an		To help mitigate the risk of replays in HTTP, this document gives an
	overview of techniques for controlling these risks in servers, and		overview of techniques for controlling these risks in servers and
	defines requirements for clients when sending requests in early data.		defines requirements for clients when sending requests in early data.
	The advice in this document also applies to use of 0-RTT in HTTP over		The advice in this document also applies to use of 0-RTT in HTTP over
	QUIC [HQ].		QUIC [HQ].
	1.1. Conventions and Definitions		1.1. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Early Data in HTTP		2. Early Data in HTTP
	Conceptually, early data is concatenated with other application data		Conceptually, early data is concatenated with other application data
	to form a single stream. This can mean that requests are entirely		to form a single stream. This can mean that requests are entirely
	contained within early data, or only part of a request is early. In		contained within early data or that only part of a request is early.
	a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ],		In a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ],
	multiple requests might be partially delivered in early data.		multiple requests might be partially delivered in early data.
	The model that this document assumes is that once the TLS handshake		The model that this document assumes is that once the TLS handshake
	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
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	2. 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. If the server		assurance that the early data was not replayed. If the server
	receives multiple requests in early data, it can determine		receives multiple requests in early data, it can determine
	whether to defer HTTP processing on a per-request basis.		whether to defer HTTP processing on a per-request basis.
	3. The server can cause a client to retry individual requests and		3. The server can cause a client to retry individual requests and
	not use early data by responding with the 425 (Too Early) status		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		code (Section 5.2) in cases where the risk of replay is judged
	too great.		too great.
	Any of these techniques is equally effective and a server can use the		All of these techniques are equally effective; a server can use the
	method that best suits it.		method that best suits it.
	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). The primary risk associated with using early		to the origin server). The primary risk associated with using early
	data is in the actions a server takes when processing a request;		data is in the actions a server takes when processing a request;
	processing a duplicated request might result in duplicated effects		processing a duplicated request might result in duplicated effects
	and side effects. Appendix E.5 of [TLS13] also describes other		and side effects. Appendix E.5 of [TLS13] also describes other
	effects produced by processing duplicated requests.		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 produce side effects with		determine this. However, some resources produce side 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 account for the possibility		handshake, all server instances need to account for the possibility
	of replay of early data and how that could affect that processing		of replay of early data and how that could affect that processing
	(see also 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 decide		Intermediary servers do not have sufficient information to decide
	whether early data can be processed, so Section 5.2 describes a way		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		for the origin to signal to them that a particular request isn't
	appropriate for early data. Intermediaries that accept early data		appropriate for early data. Intermediaries that accept early data
	MUST implement that 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 either accept all early
	or none of it. Once a server has decided to accept early data, it		data or none of it. Once a server has decided to accept early data,
	MUST process all requests in early data, even if the server rejects		it MUST process all requests in early data, even if the server
	the request by sending a 425 (Too Early) response.		rejects 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
	requests that it might defer until the handshake completes.		requests that it might defer until the 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 by 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 ([RFC7231], Section 4.2.1) in early data when it is
	it is available, and MUST NOT send unsafe methods (or methods whose		available and MUST NOT send unsafe methods (or methods whose safety
	safety is not known) in early data.		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 were 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 will need to be sent again, unless the client decides to abandon		data will need to be sent again, unless the client decides to abandon
	those 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, even though it will not		accepts and processes the early data, even though it will not
	complete the TLS handshake. The attacker then allows the original		complete the TLS handshake. The attacker then allows the original
	connection to complete. Even if the early data is detected as a		connection to complete. Even if the early data is detected as a
	duplicate and rejected, the first server instance might allow the		duplicate and rejected, the first server instance might allow the
	connection to complete. If the client then retries requests that		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 the latter would be in violation of		multiple times (though the latter would be in violation of
	requirements in 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
	set to "1" (see Section 5.1).		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 hop. Likewise, some means of explicitly triggering a		on a previous hop. Likewise, it is necessary to have some means of
	retry when early data is not desirable is necessary. Finally, it is		explicitly triggering a retry when early data is not desired.
	necessary to know whether the client will actually perform such a		Finally, it is necessary to know whether the client will actually
	retry.		perform such a retry.
	To meet these needs, two signalling mechanisms are defined:		To meet these needs, two signaling 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 completion of
	with its client completing.		the TLS handshake with its client.
	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.
	They are designed to enable better coordination of the use of 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		data between the user agent and origin server, and also when a
	gateway (also "reverse proxy", "Content Delivery Network", or		gateway (also "reverse proxy", "Content Delivery Network", or
	"surrogate") is present.		"surrogate") is present.
	Gateways typically don't have specific information about whether a		Gateways typically don't have specific information about whether a
	given request can be processed safely when it is sent in early data.		given request can be processed safely when it is sent in early data.
	In many cases, only the origin server has the necessary information		In many cases, only the origin server has the necessary information
	to decide whether the risk of replay is acceptable. These extensions		to decide whether the risk of replay is acceptable. These extensions
	allow coordination between a gateway and its origin server.		allow coordination between a gateway and its origin server.
	5.1. The Early-Data Header Field		5.1. The Early-Data Header Field
	The "Early-Data" request header field indicates that the request has		The Early-Data request header field indicates that the request has
	been conveyed in early data, and additionally indicates that a client		been conveyed in early data and that a client understands the 425
	understands the 425 (Too Early) status code.		(Too Early) status code.
	It has just one valid value: "1". Its syntax is defined by the		It has just one valid value: "1". Its syntax is defined by the
	following ABNF [ABNF]:		following ABNF [ABNF]:
	Early-Data = "1"		Early-Data = "1"
	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 - or another instance (see Section 6.2) - could have forwarded the		the request might have been subject to a replay and might already
	request prior to handshake completion if circumstances were		have been forwarded by it or another instance (see Section 6.2).
	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 header field and
	be safely processed MUST be rejected using the 425 (Too Early) status		cannot be safely processed MUST be rejected using the 425 (Too Early)
	code.		status 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 or invalid		clients MUST include at most one instance. Multiple or invalid
	instances of the header field MUST be treated as equivalent to a		instances of the header field MUST be treated as equivalent to a
	single instance with a value of 1 by a server.		single instance with a value of 1 by a server.
	A "Early-Data" header field MUST NOT be included in responses or		An 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 are expected to retry		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		the request when receiving a 425 (Too Early) response status code. A
	user agent MAY do so automatically, but any retries MUST NOT be sent		user agent SHOULD retry automatically, but any retries MUST NOT be
	in early data.		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
	unless the request is received in early data or the "Early-Data"		unless the request is received in early data or the Early-Data header
	header field is set to "1". A server SHOULD NOT emit the 425 status		field is set to "1". A server SHOULD NOT emit the 425 status code
	code unless one of these conditions is met.		unless one of these conditions is met.
	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. In		about requests or the resources those requests target. In
	particular, a request that is replayed might result in a different		particular, a request that is replayed might result in a different
	response, which might be observable from the length of protected data		response, which might be observable from the length of protected data
	even if the content remains confidential.		even if the content remains confidential.
	6.1. Gateways and Early Data		6.1. Gateways and Early Data
	A gateway MUST NOT forward requests that were received in early data		A gateway MUST NOT forward requests that were received in early data
	unless it knows that the origin server it will forward to understands		unless it knows that the origin server it will forward to understands
	the "Early-Data" header field and will correctly generate a 425 (Too		the Early-Data header field and will correctly generate a 425 (Too
	Early) status code. A gateway that is uncertain about origin server		Early) status code. A gateway that is uncertain about origin server
	support for a given request SHOULD either delay forwarding the		support for a given request SHOULD either delay forwarding the
	request until the TLS handshake with its client completes, or send a		request until the TLS handshake with its 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		the Early-Data header field expends significant effort for what can
	best be a modest performance benefit from enabling early data. If no		at best be a modest performance benefit from enabling early data. If
	origin server supports early data, disabling early data entirely is		no origin server supports early data, it is more efficient to disable
	more efficient.		early data entirely.
	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,
	early data is critical to avoiding inappropriate processing of		early data is critical to avoiding inappropriate processing of
	replayed requests. If a request is not safe to process before the		replayed requests. If a request is not safe to process before the
	TLS handshake completes, then all instances of the server (including		TLS handshake completes, then all instances of the server (including
	gateways) need to agree and either reject the request or delay		gateways) need to agree and either reject the request or delay
	processing.		processing.
	Disabling early data, delaying requests, or rejecting requests with		Disabling early data, delaying requests, or rejecting requests with
	the 425 (Too Early) status code are all equally good measures for		the 425 (Too Early) status code are all equally good measures for
	mitigating replay attacks on requests that might be vulnerable to		mitigating replay attacks on requests that might be vulnerable to
	replay. Server instances can implement any of these measures and be		replay. Server instances can implement any of these measures and be
	considered to be consistent, even if different instances use		considered consistent, even if different instances use different
	different methods. Critically, this means that it is possible to		methods. Critically, this means that it is possible to employ
	employ different mitigations in reaction to other conditions, such as		different mitigations in reaction to other conditions, such as server
	server load.		load.
	A server MUST NOT act on early data before the handshake completes if		A server MUST NOT act on early data before the handshake completes if
	it and any other server instance could make a different decision		it and any other server instance could make a different decision
	about how to handle the same data.		about how to handle the same data.
	6.3. Denial of Service		6.3. Denial of Service
	Accepting early data exposes a server to potential denial of service		Accepting early data exposes a server to potential denial of service
	through the replay of requests that are expensive to handle. A		through the replay of requests that are expensive to handle. A
	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]),
	data can arrive after the handshake completes. A server MAY process		early data can arrive after the handshake completes. A server MAY
	requests received in early data after handshake completion only if it		process requests received in early data after handshake completion
	can rely on other instances correctly handling replays of the same		only if it can rely on other instances correctly handling replays of
	requests.		the same 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 "Permanent
	Headers" registry located at https://www.iana.org/assignments/		Message Header Field Names" registry located at
	message-headers [4].		<https://www.iana.org/assignments/message-headers>.
	Header field name: Early-Data		Header field name: Early-Data
	Applicable protocol: http		Applicable protocol: http
	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 "HTTP
	"Hypertext Transfer Protocol (HTTP) Status Code" registry located at		Status Codes" registry located at <https://www.iana.org/assignments/
	https://www.iana.org/assignments/http-status-codes [5].		http-status-codes>.
	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 25 ¶		skipping to change at page 11, line 25 ¶
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.		<https://www.rfc-editor.org/info/rfc7231>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	March 2018.		<https://www.rfc-editor.org/info/rfc8446>.
	8.2. Informative References		8.2. Informative References
	[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over		[HQ] Bishop, M., "HTTP/3", draft-ietf-quic-http-34 (work in
	QUIC", draft-ietf-quic-http-13 (work in progress), June		progress), February 2021.
	2018.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/info/rfc7540>.		<https://www.rfc-editor.org/info/rfc7540>.
	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
	[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. 49 change blocks.
	96 lines changed or deleted		90 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/