< draft-ietf-httpbis-replay-01.txt		draft-ietf-httpbis-replay-02.txt >
	httpbis Working Group M. Thomson		httpbis Working Group M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track M. Nottingham		Intended status: Standards Track M. Nottingham
	Expires: April 23, 2018 Fastly		Expires: May 28, 2018 Fastly
	W. Tarreau		W. Tarreau
	HAProxy Technologies		HAProxy Technologies
	October 20, 2017		November 24, 2017
	Using Early Data in HTTP		Using Early Data in HTTP
	draft-ietf-httpbis-replay-01		draft-ietf-httpbis-replay-02
	Abstract		Abstract
	This document explains the risks of using early data for HTTP and		This document explains the risks of using early data for HTTP and
	describes techniques for reducing them. In particular, it defines a		describes techniques for reducing them. In particular, it defines a
	mechanism that enables clients to communicate with servers about		mechanism that enables clients to communicate with servers about
	early data, to assure correct operation.		early data, to assure correct operation.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 April 23, 2018.		This Internet-Draft will expire on May 28, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 26 ¶		skipping to change at page 2, line 26 ¶
	5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 7		5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 8		6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 8
	6.2. Consistent Handling of Early Data . . . . . . . . . . . . 8		6.2. Consistent Handling of Early Data . . . . . . . . . . . . 8
	6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8		6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8
	6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9		6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	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 words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	document. It's not shouting; when they are capitalized, they have		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	the special meaning defined in [RFC2119].		"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.
	2. Early Data in HTTP		2. Early Data in HTTP
	Conceptually, early data is concatenated with other application to		Conceptually, early data is concatenated with other application to
	form a single stream. This can mean that requests are entirely		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 only part of a request is early. In
	a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ],		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
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	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, they SHOULD mitigate against early data in		explicit information, they SHOULD mitigate against early data in
	requests that have unsafe methods, using the techniques outlined		requests that have unsafe methods, using the techniques outlined
	above.		above.
	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 a		server starts acting upon the contents of a request. Any time any
	server might initiate processing prior to completion of the handshake		server instance might initiate processing prior to completion of the
	it needs to consider how a possible replay of early data could affect		handshake, all server instances need to consider how a possible
	that processing (see also Section 6.2).		replay of early data could affect that processing (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 make this
	determination, so Section 5.2 describes a way for the origin to		determination, so Section 5.2 describes a way for the origin to
	signal to them that a particular request isn't appropriate for early		signal to them that a particular request isn't appropriate for early
	data. Intermediaries that accept early data MUST implement that		data. Intermediaries that accept early data MUST implement that
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 28 ¶
	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 SHOULD 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. For HTTP/2,		start sending again as though the connection was new. This could
	this means re-sending the connection preface. Any requests sent in		entail using a different negotiated protocol [ALPN] than the one
	early data MUST be sent again, unless the client decides to abandon		optimistically used for the early data. If HTTP/2 is selected after
	those requests.		early data is rejected, a client sends another connection preface.
			Any requests sent in early data MUST be sent again, unless the client
			decides to abandon those requests.
	This automatic retry exposes the request to a potential replay		This automatic retry exposes the request to a potential replay
	attack. An attacker sends early data to one server instance that		attack. An attacker sends early data to one server instance that
	accepts and processes the early data, but allows that connection to		accepts and processes the early data, but allows that connection to
	proceed no further. The attacker then forwards the same messages		proceed no further. The attacker then forwards the same messages
	from the client to another server instance that will reject early		from the client to another server instance that will reject early
	data. The client then retries the request, resulting in the request		data. The client then retries the request, resulting in the request
	being processed twice. Replays are also possible if there are		being processed twice. Replays are also possible if there are
	multiple server instances that will accept early data, or if the same		multiple server instances that will accept early data, or if the same
	server accepts early data multiple times (though this would be in		server accepts early data multiple times (though this would be in
	violation of requirements in TLS).		violation of 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
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 20 ¶
	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 connection. Likewise, some means of explicitly
	triggering a retry when early data is not desirable is necessary.		triggering a retry when early data is not desirable is necessary.
	Finally, it is necessary to know whether the client will actually		Finally, it is necessary to know whether the client will actually
	perform such a retry.		perform such a 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 are		o The "Early-Data" header field is included in requests that might
	received in early data.		have been forwarded by an intermediary prior to the TLS handshake
			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.
	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.
	skipping to change at page 7, line 38 ¶		skipping to change at page 7, line 38 ¶
	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.
	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.
	Clients (user-agents and intermediaries) that sent the request in		User agents that send a request in early data MUST automatically
	early data MUST automatically retry the request when receiving a 425		retry the request when receiving a 425 (Too Early) response status
	(Too Early) response status code. Such retries MUST NOT be sent in		code. Such retries MUST NOT be sent in early data.
	early data.
	Intermediaries that receive a 425 (Too Early) status code MAY		In all cases, an intermediary can forward a 425 (Too Early) status
	automatically retry requests after allowing the handshake to complete		code. Intermediaries MUST forward a 425 (Too Early) status code if
	unless the original request contained the "Early-Data" header field		the request that it received and forwarded contained an "Early-Data"
	when it was received. Otherwise, an intermediary MUST forward the		header field. Otherwise, an intermediary that receives a request in
	425 (Too Early) status code.		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.
	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 field is set to "1". A server SHOULD NOT emit the 425 status		header field is set to "1". A server SHOULD NOT emit the 425 status
	code unless one of these conditions is met.		code 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
	skipping to change at page 10, line 25 ¶		skipping to change at page 10, line 25 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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-21 (work in progress),		Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
	July 2017.		July 2017.
	8.2. Informative References		8.2. Informative References
			[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>.
	[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over		[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over
	QUIC", draft-ietf-quic-http-07 (work in progress), October		QUIC", draft-ietf-quic-http-07 (work in progress), October
	2017.		2017.
	[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>.
	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: Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho		document: Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho
	Oku, Kyle Rose, and Victor Vasiliev.		Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev.
	Authors' Addresses		Authors' Addresses
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	Email: martin.thomson@gmail.com		Email: martin.thomson@gmail.com
	Mark Nottingham		Mark Nottingham
	Fastly		Fastly
	Email: mnot@mnot.net		Email: mnot@mnot.net
	Willy Tarreau		Willy Tarreau
	HAProxy Technologies		HAProxy Technologies
	Email: willy@haproxy.org		Email: willy@haproxy.org
End of changes. 16 change blocks.
	30 lines changed or deleted		47 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/