< draft-ietf-httpbis-replay-02.txt		draft-ietf-httpbis-replay-03.txt >
	httpbis Working Group M. Thomson		HTTP M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track M. Nottingham		Intended status: Standards Track M. Nottingham
	Expires: May 28, 2018 Fastly		Expires: November 4, 2018 Fastly
	W. Tarreau		W. Tarreau
	HAProxy Technologies		HAProxy Technologies
	November 24, 2017		May 03, 2018
	Using Early Data in HTTP		Using Early Data in HTTP
	draft-ietf-httpbis-replay-02		draft-ietf-httpbis-replay-03
	Abstract		Abstract
	This document explains the risks of using early data for HTTP and		Using TLS early data creates an exposure to the possibility of a
	describes techniques for reducing them. In particular, it defines a		replay attack. This document defines mechanisms that allow clients
	mechanism that enables clients to communicate with servers about		to communicate with servers about HTTP requests that are sent in
	early data, to assure correct operation.		early data. Techniques are described that use these mechanisms to
			mitigate the risk of replay.
			Note to Readers
			Discussion of this draft takes place on the HTTP working group
			mailing list (ietf-http-wg@w3.org), which is archived at
			https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
			Working Group information can be found at http://httpwg.github.io/
			[2]; source code and issues list for this draft can be found at
			https://github.com/httpwg/http-extensions/labels/replay [3].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 May 28, 2018.		This Internet-Draft will expire on November 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	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 . . . . . . . . . . . . . . . 6		5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 7
	5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 7		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 . . . . . . . . . . . . . . . . . 8
	6.2. Consistent Handling of Early Data . . . . . . . . . . . . 8		6.2. Consistent Handling of Early Data . . . . . . . . . . . . 9
	6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8		6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9
	6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9		6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 11
			8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		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
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 35 ¶
	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 to		Conceptually, early data is concatenated with other application data
	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 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
	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.
	skipping to change at page 3, line 48 ¶		skipping to change at page 4, line 14 ¶
	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. TLS [TLS13] mandates the use of replay detection strategies that
	reduce the ability of an attacker to successfully replay early		reduce the ability of an attacker to successfully replay early
	data. These anti-replay techniques reduce but don't completely		data. These anti-replay techniques reduce but don't completely
	eliminate the chance of data being replayed and ensure a fixed		eliminate the chance of data being replayed and ensure a fixed
	upper limit to the number of replays.		upper limit to the number of replays.
	2. The server can choose whether it will process early data before		2. The server can reject early data. A server cannot selectively
	the TLS handshake completes. By deferring processing, it can		reject early data, so this results in all requests sent in early
	ensure that only a successfully completed connection is used for		data being discarded.
	the request(s) therein. This provides the server with some
			3. The server can choose to delay processing of early data until
			after the TLS handshake completes. By deferring processing, it
			can ensure that only a successfully completed connection is used
			for the request(s) therein. This provides the server with some
	assurance that the early data was not replayed.		assurance that the early data was not replayed.
	3. If the server receives multiple requests in early data, it can		4. If the server receives multiple requests in early data, it can
	determine whether to defer HTTP processing on a per-request		determine whether to defer HTTP processing on a per-request
	basis. This may require buffering the responses to preserve		basis.
	ordering in HTTP/1.1.
	4. The server can cause a client to retry a request and not use		5. The server can cause a client to retry a request and not use
	early data by responding with the 425 (Too Early) status code		early data by responding with the 425 (Too Early) status code
	(Section 5.2), in cases where the risk of replay is judged too		(Section 5.2), in cases where the risk of replay is judged too
	great.		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). In general, if processing a request does not
	have state-changing side effects, the consequences of replay are not		have state-changing side effects, the consequences of replay are not
	significant.		significant.
	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 elect to associate side
	effects with safe methods, so this cannot be universally relied upon.		effects with 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, they SHOULD mitigate against early data in		explicit information, origin servers MUST either reject early data or
	requests that have unsafe methods, using the techniques outlined		implement the techniques described in this document for ensuring that
	above.		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 consider how a possible
	replay of early data could affect that processing (see also		replay of early data could affect that processing (see also
	Section 6.2).		Section 6.2).
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 48 ¶
	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. This could		start sending again as though the connection was 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. If HTTP/2 is selected after		optimistically used for the early data. Any requests sent in early
	early data is rejected, a client sends another connection preface.		data MUST be sent again, unless the client decides to abandon those
	Any requests sent in early data MUST be sent again, unless the client		requests.
	decides to abandon those requests.
	This automatic retry exposes the request to a potential replay		Automatic retry creates the potential for a replay attack. An
	attack. An attacker sends early data to one server instance that		attacker intercepts a connection that uses early data and copies the
	accepts and processes the early data, but allows that connection to		early data to another server instance. The second server instance
	proceed no further. The attacker then forwards the same messages		accepts and processes the early data. The attacker then allows the
	from the client to another server instance that will reject early		original connection to complete. Even if the early data is detected
	data. The client then retries the request, resulting in the request		as a duplicate and rejected, the first server instance might allow
	being processed twice. Replays are also possible if there are		the connection to complete. If the client then retries requests that
	multiple server instances that will accept early data, or if the same		were sent in early data, the request will be processed twice.
	server accepts early data multiple times (though this would be in
	violation of requirements in Section 8 of [TLS13]).		Replays are also possible if there are multiple server instances that
			will accept early data, or if the same server accepts early data
			multiple times (though this would be in 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 22 ¶		skipping to change at page 6, line 43 ¶
	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 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
	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.
	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 10 ¶		skipping to change at page 7, line 29 ¶
	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 MUST send it with the "Early-Data" header field set		the TLS handshake with its client MUST send it with the "Early-Data"
	to "1" (i.e., it adds it if not present in the request). An		header field set to "1" (i.e., it adds it if not present in the
	intermediary MUST use the "Early-Data" header field if it might have		request). An intermediary MUST use the "Early-Data" header field if
	forwarded the request prior to handshake completion (see Section 6.2		it might have forwarded the request prior to handshake completion
	for details).		(see Section 6.2 for details).
	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.		a request. "Early-Data" MUST NOT appear in a "Connection" header
			field.
	The "Early-Data" header field is not intended for use by user agents		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
			clients MUST include at most one instance. Multiple instances MUST
			be treated as equivalent to a single instance by a server.
			A "Early-Data" header field MUST NOT be included in responses or
			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 MUST automatically
	retry the request when receiving a 425 (Too Early) response status		retry the request when receiving a 425 (Too Early) response status
	code. Such retries MUST NOT be sent in early data.		code. Such 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
	skipping to change at page 8, line 23 ¶		skipping to change at page 8, line 50 ¶
	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.
	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 that forwards requests that were received in early data
	MUST only do so if it knows that the origin server that receives		MUST only do so if it knows that the origin server that receives
	those requests understands the "Early-Data" header field and will		those requests understands the "Early-Data" header field and will
	correctly generate a 425 (Too Early) status code. A gateway that		correctly generate a 425 (Too Early) status code. A gateway that is
	isn't certain about origin server support SHOULD either delay		uncertain about origin server support for a given request SHOULD
	forwarding the request until the TLS handshake with its client		either delay forwarding the request until the TLS handshake with its
	completes, or send a 425 (Too Early) status code in response. A		client completes, or send a 425 (Too Early) status code in response.
	gateway that is uncertain about whether an origin server supports the
	"Early-Data" header field SHOULD disable early data.		A gateway without at least one potential origin server that supports
			"Early-Data" header field expends significant effort for what can at
			best be a modest performance benefit from enabling early data. If no
			origin server supports early data, disabling early data entirely is
			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 -
	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
			the 425 (Too Early) status code are all equally good measures for
			mitigating replay attacks on requests that might be vulnerable to
			replay. Server instances can implement any of these measures and be
			considered to be consistent, even if different instances use
			different methods. Critically, this means that it is possible to
			employ different mitigations in reaction to other conditions, such as
			server load.
	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]) early
	data can arrive after the handshake completes. This leads to		data can arrive after the handshake completes. A server MAY process
	potential ambiguity about the status of requests and could lead to		requests received in early data after handshake completion if it can
	inconsistent treatment (see Section 6.2). Implementations MUST		rely on other instances correctly handling replays of the same
	either ensure that any early data that is delivered late is either		requests.
	discarded or consistently identified and processed.
	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 [HEADERS].		Headers" registry located at https://www.iana.org/assignments/
			message-headers [4].
	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
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 42 ¶
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,
	<https://www.rfc-editor.org/info/rfc3864>.
	[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[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		[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-21 (work in progress),		Version 1.3", draft-ietf-tls-tls13-22 (work in progress),
	July 2017.		November 2017.
	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., "Hypertext Transfer Protocol (HTTP) over
	QUIC", draft-ietf-quic-http-07 (work in progress), October		QUIC", draft-ietf-quic-http-08 (work in progress),
	2017.		December 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>.
			8.3. URIs
			[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
			[2] http://httpwg.github.io/
			[3] https://github.com/httpwg/http-extensions/labels/replay
			[4] https://www.iana.org/assignments/message-headers
	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: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari
	Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev.		Liusavaara, Kazuho 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
End of changes. 32 change blocks.
	76 lines changed or deleted		120 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/