draft-ietf-quic-tls-07.txt		draft-ietf-quic-tls-08.txt
	QUIC M. Thomson, Ed.		QUIC M. Thomson, Ed.
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track S. Turner, Ed.		Intended status: Standards Track S. Turner, Ed.
	Expires: April 16, 2018 sn3rd		Expires: June 8, 2018 sn3rd
	October 13, 2017		December 5, 2017
	Using Transport Layer Security (TLS) to Secure QUIC		Using Transport Layer Security (TLS) to Secure QUIC
	draft-ietf-quic-tls-07		draft-ietf-quic-tls-08
	Abstract		Abstract
	This document describes how Transport Layer Security (TLS) is used to		This document describes how Transport Layer Security (TLS) is used to
	secure QUIC.		secure QUIC.
	Note to Readers		Note to Readers
	Discussion of this draft takes place on the QUIC working group		Discussion of this draft takes place on the QUIC working group
	mailing list (quic@ietf.org), which is archived at		mailing list (quic@ietf.org), which is archived at
	https://mailarchive.ietf.org/arch/search/?email_list=quic [1].		https://mailarchive.ietf.org/arch/search/?email_list=quic [1].
	Working Group information can be found at https://github.com/quicwg		Working Group information can be found at https://github.com/quicwg
	[2]; source code and issues list for this draft can be found at		[2]; source code and issues list for this draft can be found at
	https://github.com/quicwg/base-drafts/labels/tls [3].		https://github.com/quicwg/base-drafts/labels/-tls [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 April 16, 2018.		This Internet-Draft will expire on June 8, 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 37 ¶		skipping to change at page 2, line 37 ¶
	4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 11		4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 11
	4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12		4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12
	4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12		4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12
	4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13		4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13
	4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13		4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13
	4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 13		4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 13
	4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14		4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14
	5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14		5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14
	5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 14		5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 14
	5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 15		5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 15
	5.2.1. Cleartext Packet Secrets . . . . . . . . . . . . . . 15		5.2.1. Handshake Secrets . . . . . . . . . . . . . . . . . . 15
	5.2.2. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 16		5.2.2. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 16
	5.2.3. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 16		5.2.3. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 16
	5.2.4. Packet Protection Key and IV . . . . . . . . . . . . 17		5.2.4. Packet Protection Key and IV . . . . . . . . . . . . 17
	5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 18		5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 18
	5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 19		5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 19
	5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19		5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19
	5.6. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 20		5.6. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 20
	6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20		6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.1. Packet Protection for the TLS Handshake . . . . . . . . . 20		6.1. Packet Protection for the TLS Handshake . . . . . . . . . 20
	6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 21		6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 21
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	7.1. HelloRetryRequest Address Validation . . . . . . . . . . 24		7.1. HelloRetryRequest Address Validation . . . . . . . . . . 24
	7.1.1. Stateless Address Validation . . . . . . . . . . . . 25		7.1.1. Stateless Address Validation . . . . . . . . . . . . 25
	7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 25		7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 25
	7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25		7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25
	7.3. Address Validation Token Integrity . . . . . . . . . . . 26		7.3. Address Validation Token Integrity . . . . . . . . . . . 26
	8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26		8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26
	8.1. Unprotected Packets Prior to Handshake Completion . . . . 27		8.1. Unprotected Packets Prior to Handshake Completion . . . . 27
	8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27		8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27
	8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28		8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28
	8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 28		8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 28
	8.1.4. Denial of Service with Unprotected Packets . . . . . 29		8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 29
	8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 29		8.1.5. Denial of Service with Unprotected Packets . . . . . 29
			8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30
	8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30		8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30
	9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30		9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30
	9.1. Protocol and Version Negotiation . . . . . . . . . . . . 30		9.1. Protocol and Version Negotiation . . . . . . . . . . . . 31
	9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31		9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31
	9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 31		9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 32
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 32		10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32		10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32
	10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 32		10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33
	11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33		11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	13.1. Normative References . . . . . . . . . . . . . . . . . . 34		13.1. Normative References . . . . . . . . . . . . . . . . . . 35
	13.2. Informative References . . . . . . . . . . . . . . . . . 35		13.2. Informative References . . . . . . . . . . . . . . . . . 36
	13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36		13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 37
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37
	C.1. Since draft-ietf-quic-tls-06 . . . . . . . . . . . . . . 36		C.1. Since draft-ietf-quic-tls-06 . . . . . . . . . . . . . . 37
	C.2. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 36		C.2. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 37
	C.3. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37		C.3. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37
	C.4. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 37		C.4. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 37
	C.5. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 37		C.5. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 37
	C.6. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 37		C.6. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 37
	C.7. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 37		C.7. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 38
	C.8. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 38		C.8. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	This document describes how QUIC [QUIC-TRANSPORT] is secured using		This document describes how QUIC [QUIC-TRANSPORT] is secured using
	Transport Layer Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS		Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides
	1.3 provides critical latency improvements for connection		critical latency improvements for connection establishment over
	establishment over previous versions. Absent packet loss, most new		previous versions. Absent packet loss, most new connections can be
	connections can be established and secured within a single round		established and secured within a single round trip; on subsequent
	trip; on subsequent connections between the same client and server,		connections between the same client and server, the client can often
	the client can often send application data immediately, that is,		send application data immediately, that is, using a zero round trip
	using a zero round trip setup.		setup.
	This document describes how the standardized TLS 1.3 acts a security		This document describes how the standardized TLS 1.3 acts a security
	component of QUIC. The same design could work for TLS 1.2, though		component of QUIC. The same design could work for TLS 1.2, though
	few of the benefits QUIC provides would be realized due to the		few of the benefits QUIC provides would be realized due to the
	handshake latency in versions of TLS prior to 1.3.		handshake latency in versions of TLS prior to 1.3.
	2. Notational Conventions		2. Notational Conventions
	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.
	This document uses the terminology established in [QUIC-TRANSPORT].		This document uses the terminology established in [QUIC-TRANSPORT].
	For brevity, the acronym TLS is used to refer to TLS 1.3.		For brevity, the acronym TLS is used to refer to TLS 1.3.
	TLS terminology is used when referring to parts of TLS. Though TLS		TLS terminology is used when referring to parts of TLS. Though TLS
	assumes a continuous stream of octets, it divides that stream into		assumes a continuous stream of octets, it divides that stream into
	_records_. Most relevant to QUIC are the records that contain TLS		_records_. Most relevant to QUIC are the records that contain TLS
	_handshake messages_, which are discrete messages that are used for		_handshake messages_, which are discrete messages that are used for
	key agreement, authentication and parameter negotiation. Ordinarily,		key agreement, authentication and parameter negotiation. Ordinarily,
	TLS records can also contain _application data_, though in the QUIC		TLS records can also contain _application data_, though in the QUIC
	usage there is no use of TLS application data.		usage there is no use of TLS application data.
	3. Protocol Overview		3. Protocol Overview
	QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality		QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality
	and integrity protection of packets. For this it uses keys derived		and integrity protection of packets. For this it uses keys derived
	from a TLS 1.3 connection [I-D.ietf-tls-tls13]; QUIC also relies on		from a TLS 1.3 connection [TLS13]; QUIC also relies on TLS 1.3 for
	TLS 1.3 for authentication and negotiation of parameters that are		authentication and negotiation of parameters that are critical to
	critical to security and performance.		security and performance.
	Rather than a strict layering, these two protocols are co-dependent:		Rather than a strict layering, these two protocols are co-dependent:
	QUIC uses the TLS handshake; TLS uses the reliability and ordered		QUIC uses the TLS handshake; TLS uses the reliability and ordered
	delivery provided by QUIC streams.		delivery provided by QUIC streams.
	This document defines how QUIC interacts with TLS. This includes a		This document defines how QUIC interacts with TLS. This includes a
	description of how TLS is used, how keying material is derived from		description of how TLS is used, how keying material is derived from
	TLS, and the application of that keying material to protect QUIC		TLS, and the application of that keying material to protect QUIC
	packets. Figure 1 shows the basic interactions between TLS and QUIC,		packets. Figure 1 shows the basic interactions between TLS and QUIC,
	with the QUIC packet protection being called out specially.		with the QUIC packet protection being called out specially.
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	responds after receiving the first handshake message from the		responds after receiving the first handshake message from the
	client.		client.
	o A 0-RTT handshake in which the client uses information it has		o A 0-RTT handshake in which the client uses information it has
	previously learned about the server to send application data		previously learned about the server to send application data
	immediately. This application data can be replayed by an attacker		immediately. This application data can be replayed by an attacker
	so it MUST NOT carry a self-contained trigger for any non-		so it MUST NOT carry a self-contained trigger for any non-
	idempotent action.		idempotent action.
	A simplified TLS 1.3 handshake with 0-RTT application data is shown		A simplified TLS 1.3 handshake with 0-RTT application data is shown
	in Figure 2, see [I-D.ietf-tls-tls13] for more options and details.		in Figure 2, see [TLS13] for more options and details.
	Client Server		Client Server
	ClientHello		ClientHello
	(0-RTT Application Data) -------->		(0-RTT Application Data) -------->
	ServerHello		ServerHello
	{EncryptedExtensions}		{EncryptedExtensions}
	{Finished}		{Finished}
	<-------- [Application Data]		<-------- [Application Data]
	(EndOfEarlyData)		(EndOfEarlyData)
	skipping to change at page 7, line 43 ¶		skipping to change at page 7, line 43 ¶
	protection for the TLS handshake messages sent by the server.		protection for the TLS handshake messages sent by the server.
	QUIC permits a client to send frames on streams starting from the		QUIC permits a client to send frames on streams starting from the
	first packet. The initial packet from a client contains a stream		first packet. The initial packet from a client contains a stream
	frame for stream 0 that contains the first TLS handshake messages		frame for stream 0 that contains the first TLS handshake messages
	from the client. This allows the TLS handshake to start with the		from the client. This allows the TLS handshake to start with the
	first packet that a client sends.		first packet that a client sends.
	QUIC packets are protected using a scheme that is specific to QUIC,		QUIC packets are protected using a scheme that is specific to QUIC,
	see Section 5. Keys are exported from the TLS connection when they		see Section 5. Keys are exported from the TLS connection when they
	become available using a TLS exporter (see Section 7.5 of		become available using a TLS exporter (see Section 7.5 of [TLS13] and
	[I-D.ietf-tls-tls13] and Section 5.2). After keys are exported from		Section 5.2). After keys are exported from TLS, QUIC manages its own
	TLS, QUIC manages its own key schedule.		key schedule.
	4.1. Handshake and Setup Sequence		4.1. Handshake and Setup Sequence
	The integration of QUIC with a TLS handshake is shown in more detail		The integration of QUIC with a TLS handshake is shown in more detail
	in Figure 3. QUIC "STREAM" frames on stream 0 carry the TLS		in Figure 3. QUIC "STREAM" frames on stream 0 carry the TLS
	handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this		handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this
	stream and ensures that TLS handshake messages are delivered in the		stream and ensures that TLS handshake messages are delivered in the
	correct order.		correct order.
	Client Server		Client Server
	@C QUIC STREAM Frame(s) <0>:		@H QUIC STREAM Frame(s) <0>:
	ClientHello		ClientHello
	+ QUIC Extension		+ QUIC Extension
	-------->		-------->
	0-RTT Key => @0		0-RTT Key => @0
	@0 QUIC STREAM Frame(s) <any stream>:		@0 QUIC STREAM Frame(s) <any stream>:
	Replayable QUIC Frames		Replayable QUIC Frames
	-------->		-------->
	QUIC STREAM Frame <0>: @C		QUIC STREAM Frame <0>: @H
	ServerHello		ServerHello
	{TLS Handshake Messages}		{TLS Handshake Messages}
	<--------		<--------
	1-RTT Key => @1		1-RTT Key => @1
	QUIC Frames <any> @1		QUIC Frames <any> @1
	<--------		<--------
	@C QUIC STREAM Frame(s) <0>:		@H QUIC STREAM Frame(s) <0>:
	(EndOfEarlyData)		(EndOfEarlyData)
	{Finished}		{Finished}
	-------->		-------->
	@1 QUIC Frames <any> <-------> QUIC Frames <any> @1		@1 QUIC Frames <any> <-------> QUIC Frames <any> @1
	Figure 3: QUIC over TLS Handshake		Figure 3: QUIC over TLS Handshake
	In Figure 3, symbols mean:		In Figure 3, symbols mean:
	o "<" and ">" enclose stream numbers.		o "<" and ">" enclose stream numbers.
	o "@" indicates the keys that are used for protecting the QUIC		o "@" indicates the keys that are used for protecting the QUIC
	packet (C = cleartext, with integrity only; 0 = 0-RTT keys; 1 =		packet (H = handshake, using keys from the well-known cleartext
	1-RTT keys).		packet secret; 0 = 0-RTT keys; 1 = 1-RTT keys).
	o "(" and ")" enclose messages that are protected with TLS 0-RTT		o "(" and ")" enclose messages that are protected with TLS 0-RTT
	handshake or application keys.		handshake or application keys.
	o "{" and "}" enclose messages that are protected by the TLS		o "{" and "}" enclose messages that are protected by the TLS
	Handshake keys.		Handshake keys.
	If 0-RTT is not attempted, then the client does not send packets		If 0-RTT is not attempted, then the client does not send packets
	protected by the 0-RTT key (@0). In that case, the only key		protected by the 0-RTT key (@0). In that case, the only key
	transition on the client is from cleartext packets (@C) to 1-RTT		transition on the client is from handshake packets (@H) to 1-RTT
	protection (@1), which happens after it sends its final set of TLS		protection (@1), which happens after it sends its final set of TLS
	handshake messages.		handshake messages.
	Note: the client uses two different types of cleartext packet during		Note: two different types of packet are used during the handshake by
	the handshake. The Client Initial packet carries a TLS ClientHello		both client and server. The Initial packet carries a TLS ClientHello
	message; the remainder of the TLS handshake is carried in Client		message; the remainder of the TLS handshake is carried in Handshake
	Cleartext packets.		packets. The Retry packet carries a TLS HelloRetryRequest, if it is
			needed, and Handshake packets carry the remainder of the server
			handshake.
	The server sends TLS handshake messages without protection (@C). The		The server sends TLS handshake messages without protection (@H). The
	server transitions from no protection (@C) to full 1-RTT protection		server transitions from no protection (@H) to full 1-RTT protection
	(@1) after it sends the last of its handshake messages.		(@1) after it sends the last of its handshake messages.
	Some TLS handshake messages are protected by the TLS handshake record		Some TLS handshake messages are protected by the TLS handshake record
	protection. These keys are not exported from the TLS connection for		protection. These keys are not exported from the TLS connection for
	use in QUIC. QUIC packets from the server are sent in the clear		use in QUIC. QUIC packets from the server are sent in the clear
	until the final transition to 1-RTT keys.		until the final transition to 1-RTT keys.
	The client transitions from cleartext (@C) to 0-RTT keys (@0) when		The client transitions from handshake (@H) to 0-RTT keys (@0) when
	sending 0-RTT data, and subsequently to to 1-RTT keys (@1) after its		sending 0-RTT data, and subsequently to to 1-RTT keys (@1) after its
	second flight of TLS handshake messages. This creates the potential		second flight of TLS handshake messages. This creates the potential
	for unprotected packets to be received by a server in close proximity		for unprotected packets to be received by a server in close proximity
	to packets that are protected with 1-RTT keys.		to packets that are protected with 1-RTT keys.
	More information on key transitions is included in Section 6.1.		More information on key transitions is included in Section 6.1.
	4.2. Interface to TLS		4.2. Interface to TLS
	As shown in Figure 1, the interface from QUIC to TLS consists of four		As shown in Figure 1, the interface from QUIC to TLS consists of four
	skipping to change at page 12, line 4 ¶		skipping to change at page 11, line 51 ¶
	immediately after TLS is provided with new handshake octets, or after		immediately after TLS is provided with new handshake octets, or after
	TLS produces handshake octets.		TLS produces handshake octets.
	When TLS completed its handshake, 1-RTT keys can be provided to QUIC.		When TLS completed its handshake, 1-RTT keys can be provided to QUIC.
	On both client and server, this occurs after sending the TLS Finished		On both client and server, this occurs after sending the TLS Finished
	message.		message.
	This ordering means that there could be frames that carry TLS		This ordering means that there could be frames that carry TLS
	handshake messages ready to send at the same time that application		handshake messages ready to send at the same time that application
	data is available. An implementation MUST ensure that TLS handshake		data is available. An implementation MUST ensure that TLS handshake
	messages are always sent in cleartext packets. Separate packets are		messages are always sent in packets protected with handshake keys
	required for data that needs protection from 1-RTT keys.		(see Section 5.2.1). Separate packets are required for data that
			needs protection from 1-RTT keys.
	If 0-RTT is possible, it is ready after the client sends a TLS		If 0-RTT is possible, it is ready after the client sends a TLS
	ClientHello message or the server receives that message. After		ClientHello message or the server receives that message. After
	providing a QUIC client with the first handshake octets, the TLS		providing a QUIC client with the first handshake octets, the TLS
	stack might signal that 0-RTT keys are ready. On the server, after		stack might signal that 0-RTT keys are ready. On the server, after
	receiving handshake octets that contain a ClientHello message, a TLS		receiving handshake octets that contain a ClientHello message, a TLS
	server might signal that 0-RTT keys are available.		server might signal that 0-RTT keys are available.
	1-RTT keys are used for packets in both directions. 0-RTT keys are		1-RTT keys are used for packets in both directions. 0-RTT keys are
	only used to protect packets sent by the client.		only used to protect packets sent by the client.
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	Get Handshake		Get Handshake
	Handshake Complete		Handshake Complete
	<--- send/receive ---		<--- send/receive ---
	Handshake Received		Handshake Received
	Get Handshake		Get Handshake
	Figure 4: Interaction Summary between QUIC and TLS		Figure 4: Interaction Summary between QUIC and TLS
	4.3. TLS Version		4.3. TLS Version
	This document describes how TLS 1.3 [I-D.ietf-tls-tls13] is used with		This document describes how TLS 1.3 [TLS13] is used with QUIC.
	QUIC.
	In practice, the TLS handshake will negotiate a version of TLS to		In practice, the TLS handshake will negotiate a version of TLS to
	use. This could result in a newer version of TLS than 1.3 being		use. This could result in a newer version of TLS than 1.3 being
	negotiated if both endpoints support that version. This is		negotiated if both endpoints support that version. This is
	acceptable provided that the features of TLS 1.3 that are used by		acceptable provided that the features of TLS 1.3 that are used by
	QUIC are supported by the newer version.		QUIC are supported by the newer version.
	A badly configured TLS implementation could negotiate TLS 1.2 or		A badly configured TLS implementation could negotiate TLS 1.2 or
	another older version of TLS. An endpoint MUST terminate the		another older version of TLS. An endpoint MUST terminate the
	connection if a version of TLS older than 1.3 is negotiated.		connection if a version of TLS older than 1.3 is negotiated.
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 11 ¶
	typically involves verification that the identity of the server is		typically involves verification that the identity of the server is
	included in a certificate and that the certificate is issued by a		included in a certificate and that the certificate is issued by a
	trusted entity (see for example [RFC2818]).		trusted entity (see for example [RFC2818]).
	A server MAY request that the client authenticate during the		A server MAY request that the client authenticate during the
	handshake. A server MAY refuse a connection if the client is unable		handshake. A server MAY refuse a connection if the client is unable
	to authenticate when requested. The requirements for client		to authenticate when requested. The requirements for client
	authentication vary based on application protocol and deployment.		authentication vary based on application protocol and deployment.
	A server MUST NOT use post-handshake client authentication (see		A server MUST NOT use post-handshake client authentication (see
	Section 4.6.2 of [I-D.ietf-tls-tls13]).		Section 4.6.2 of [TLS13]).
	4.6. TLS Errors		4.6. TLS Errors
	Errors in the TLS connection SHOULD be signaled using TLS alerts on		Errors in the TLS connection SHOULD be signaled using TLS alerts on
	stream 0. A failure in the handshake MUST be treated as a QUIC		stream 0. A failure in the handshake MUST be treated as a QUIC
	connection error of type TLS_HANDSHAKE_FAILED. Once the handshake is		connection error of type TLS_HANDSHAKE_FAILED. Once the handshake is
	complete, an error in the TLS connection that causes a TLS alert to		complete, an error in the TLS connection that causes a TLS alert to
	be sent or received MUST be treated as a QUIC connection error of		be sent or received MUST be treated as a QUIC connection error of
	type TLS_FATAL_ALERT_GENERATED or TLS_FATAL_ALERT_RECEIVED		type TLS_FATAL_ALERT_GENERATED or TLS_FATAL_ALERT_RECEIVED
	respectively.		respectively.
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 44 ¶
	protection. These messages are limited in number, and so the		protection. These messages are limited in number, and so the
	additional overhead is small.		additional overhead is small.
	5.1. Installing New Keys		5.1. Installing New Keys
	As TLS reports the availability of keying material, the packet		As TLS reports the availability of keying material, the packet
	protection keys and initialization vectors (IVs) are updated (see		protection keys and initialization vectors (IVs) are updated (see
	Section 5.2). The selection of AEAD function is also updated to		Section 5.2). The selection of AEAD function is also updated to
	match the AEAD negotiated by TLS.		match the AEAD negotiated by TLS.
	For packets other than any unprotected handshake packets (see		For packets other than any handshake packets (see Section 6.1), once
	Section 6.1), once a change of keys has been made, packets with		a change of keys has been made, packets with higher packet numbers
	higher packet numbers MUST be sent with the new keying material. The		MUST be sent with the new keying material. The KEY_PHASE bit on
	KEY_PHASE bit on these packets is inverted each time new keys are		these packets is inverted each time new keys are installed to signal
	installed to signal the use of the new keys to the recipient (see		the use of the new keys to the recipient (see Section 6 for details).
	Section 6 for details).
	An endpoint retransmits stream data in a new packet. New packets		An endpoint retransmits stream data in a new packet. New packets
	have new packet numbers and use the latest packet protection keys.		have new packet numbers and use the latest packet protection keys.
	This simplifies key management when there are key updates (see		This simplifies key management when there are key updates (see
	Section 6.2).		Section 6.2).
	5.2. QUIC Key Expansion		5.2. QUIC Key Expansion
	QUIC uses a system of packet protection secrets, keys and IVs that		QUIC uses a system of packet protection secrets, keys and IVs that
	are modelled on the system used in TLS [I-D.ietf-tls-tls13]. The		are modelled on the system used in TLS [TLS13]. The secrets that
	secrets that QUIC uses as the basis of its key schedule are obtained		QUIC uses as the basis of its key schedule are obtained using TLS
	using TLS exporters (see Section 7.5 of [I-D.ietf-tls-tls13]).		exporters (see Section 7.5 of [TLS13]).
	QUIC uses HKDF with the same hash function negotiated by TLS for key		QUIC uses HKDF with the same hash function negotiated by TLS for key
	derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256,		derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256,
	the SHA-256 hash function is used.		the SHA-256 hash function is used.
	5.2.1. Cleartext Packet Secrets		5.2.1. Handshake Secrets
	Cleartext packets are protected with secrets derived from the		Packets that carry the TLS handshake (Initial, Retry, and Handshake)
	client's connection ID. Specifically:		are protected with secrets derived from the connection ID used in the
			client's Initial packet. Specifically:
	quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639		quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639
	cleartext_secret = HKDF-Extract(quic_version_1_salt,		handshake_secret = HKDF-Extract(quic_version_1_salt,
	client_connection_id)		client_connection_id)
	client_cleartext_secret =		client_handshake_secret =
	HKDF-Expand-Label(cleartext_secret,		HKDF-Expand-Label(handshake_secret,
	"QUIC client cleartext Secret",		"QUIC client handshake secret",
	"", Hash.length)		"", Hash.length)
	server_cleartext_secret =		server_handshake_secret =
	HKDF-Expand-Label(cleartext_secret,		HKDF-Expand-Label(handshake_secret,
	"QUIC server cleartext Secret",		"QUIC server handshake secret",
	"", Hash.length)		"", Hash.length)
	The HKDF for the cleartext packet protection keys uses the SHA-256		The HKDF for the handshake secrets and keys derived from them uses
	hash function [FIPS180].		the SHA-256 hash function [FIPS180].
	The salt value is a 20 octet sequence shown in the figure in		The salt value is a 20 octet sequence shown in the figure in
	hexadecimal notation. Future versions of QUIC SHOULD generate a new		hexadecimal notation. Future versions of QUIC SHOULD generate a new
	salt value, thus ensuring that the keys are different for each		salt value, thus ensuring that the keys are different for each
	version of QUIC. This prevents a middlebox that only recognizes one		version of QUIC. This prevents a middlebox that only recognizes one
	version of QUIC from seeing or modifying the contents of cleartext		version of QUIC from seeing or modifying the contents of handshake
	packets from future versions.		packets from future versions.
	5.2.2. 0-RTT Secret		5.2.2. 0-RTT Secret
	0-RTT keys are those keys that are used in resumed connections prior		0-RTT keys are those keys that are used in resumed connections prior
	to the completion of the TLS handshake. Data sent using 0-RTT keys		to the completion of the TLS handshake. Data sent using 0-RTT keys
	might be replayed and so has some restrictions on its use, see		might be replayed and so has some restrictions on its use, see
	Section 8.2. 0-RTT keys are used after sending or receiving a		Section 8.2. 0-RTT keys are used after sending or receiving a
	ClientHello.		ClientHello.
	skipping to change at page 16, line 48 ¶		skipping to change at page 16, line 48 ¶
	= TLS-Exporter("EXPORTER-QUIC client 1-RTT Secret"		= TLS-Exporter("EXPORTER-QUIC client 1-RTT Secret"
	"", Hash.length)		"", Hash.length)
	server_pp_secret_0		server_pp_secret_0
	= TLS-Exporter("EXPORTER-QUIC server 1-RTT Secret"		= TLS-Exporter("EXPORTER-QUIC server 1-RTT Secret"
	"", Hash.length)		"", Hash.length)
	These secrets are used to derive the initial client and server packet		These secrets are used to derive the initial client and server packet
	protection keys.		protection keys.
	After a key update (see Section 6.2), these secrets are updated using		After a key update (see Section 6.2), these secrets are updated using
	the HKDF-Expand-Label function defined in Section 7.1 of		the HKDF-Expand-Label function defined in Section 7.1 of [TLS13].
	[I-D.ietf-tls-tls13]. HKDF-Expand-Label uses the PRF hash function		HKDF-Expand-Label uses the PRF hash function negotiated by TLS. The
	negotiated by TLS. The replacement secret is derived using the		replacement secret is derived using the existing Secret, a Label of
	existing Secret, a Label of "QUIC client 1-RTT Secret" for the client		"QUIC client 1-RTT Secret" for the client and "QUIC server 1-RTT
	and "QUIC server 1-RTT Secret" for the server, an empty HashValue,		Secret" for the server, an empty HashValue, and the same output
	and the same output Length as the hash function selected by TLS for		Length as the hash function selected by TLS for its PRF.
	its PRF.
	client_pp_secret_<N+1>		client_pp_secret_<N+1>
	= HKDF-Expand-Label(client_pp_secret_<N>,		= HKDF-Expand-Label(client_pp_secret_<N>,
	"QUIC client 1-RTT Secret",		"QUIC client 1-RTT Secret",
	"", Hash.length)		"", Hash.length)
	server_pp_secret_<N+1>		server_pp_secret_<N+1>
	= HKDF-Expand-Label(server_pp_secret_<N>,		= HKDF-Expand-Label(server_pp_secret_<N>,
	"QUIC server 1-RTT Secret",		"QUIC server 1-RTT Secret",
	"", Hash.length)		"", Hash.length)
	skipping to change at page 17, line 41 ¶		skipping to change at page 17, line 41 ¶
	For example, the client packet protection secret uses an info		For example, the client packet protection secret uses an info
	parameter of:		parameter of:
	info = (HashLen / 256) || (HashLen % 256) || 0x1f ||		info = (HashLen / 256) || (HashLen % 256) || 0x1f ||
	"tls13 QUIC client 1-RTT secret" || 0x00		"tls13 QUIC client 1-RTT secret" || 0x00
	5.2.4. Packet Protection Key and IV		5.2.4. Packet Protection Key and IV
	The complete key expansion uses an identical process for key		The complete key expansion uses an identical process for key
	expansion as defined in Section 7.3 of [I-D.ietf-tls-tls13], using		expansion as defined in Section 7.3 of [TLS13], using different
	different values for the input secret. QUIC uses the AEAD function		values for the input secret. QUIC uses the AEAD function negotiated
	negotiated by TLS.		by TLS.
	The packet protection key and IV used to protect the 0-RTT packets		The packet protection key and IV used to protect the 0-RTT packets
	sent by a client are derived from the QUIC 0-RTT secret. The packet		sent by a client are derived from the QUIC 0-RTT secret. The packet
	protection keys and IVs for 1-RTT packets sent by the client and		protection keys and IVs for 1-RTT packets sent by the client and
	server are derived from the current generation of client_pp_secret		server are derived from the current generation of client_pp_secret
	and server_pp_secret respectively. The length of the output is		and server_pp_secret respectively. The length of the output is
	determined by the requirements of the AEAD function selected by TLS.		determined by the requirements of the AEAD function selected by TLS.
	The key length is the AEAD key size. As defined in Section 5.3 of		All ciphersuites currently used for QUIC have a 16-byte
			authentication tag and produce an ouput 16 bytes larger than their
	[I-D.ietf-tls-tls13], the IV length is the larger of 8 or N_MIN (see		input. The key length is the AEAD key size. As defined in
	Section 4 of [RFC5116]). For any secret S, the corresponding key and		Section 5.3 of [TLS13], the IV length is the larger of 8 or N_MIN
	IV are derived as shown below:		(see Section 4 of [AEAD]; all ciphersuites defined in [TLS13] have
			N_MIN set to 12). For any secret S, the corresponding key and IV are
			derived as shown below:
	key = HKDF-Expand-Label(S, "key", "", key_length)		key = HKDF-Expand-Label(S, "key", "", key_length)
	iv = HKDF-Expand-Label(S, "iv", "", iv_length)		iv = HKDF-Expand-Label(S, "iv", "", iv_length)
	The QUIC record protection initially starts without keying material.		The QUIC record protection initially starts without keying material.
	When the TLS state machine reports that the ClientHello has been		When the TLS state machine reports that the ClientHello has been
	sent, the 0-RTT keys can be generated and installed for writing.		sent, the 0-RTT keys can be generated and installed for writing.
	When the TLS state machine reports completion of the handshake, the		When the TLS state machine reports completion of the handshake, the
	1-RTT keys can be generated and installed for writing.		1-RTT keys can be generated and installed for writing.
	5.3. QUIC AEAD Usage		5.3. QUIC AEAD Usage
	The Authentication Encryption with Associated Data (AEAD) [RFC5116]		The Authentication Encryption with Associated Data (AEAD) [AEAD]
	function used for QUIC packet protection is AEAD that is negotiated		function used for QUIC packet protection is AEAD that is negotiated
	for use with the TLS connection. For example, if TLS is using the		for use with the TLS connection. For example, if TLS is using the
	TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used.		TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used.
	All QUIC packets other than Version Negotiation and Stateless Reset		All QUIC packets other than Version Negotiation and Stateless Reset
	packets are protected with an AEAD algorithm [RFC5116]. Cleartext		packets are protected with an AEAD algorithm [AEAD]. Cleartext
	packets are protected with AEAD_AES_128_GCM and a key derived from		packets are protected with AEAD_AES_128_GCM and a key derived from
	the client's connection ID (see Section 5.2.1). This provides		the client's connection ID (see Section 5.2.1). This provides
	protection against off-path attackers and robustness against QUIC		protection against off-path attackers and robustness against QUIC
	version unaware middleboxes, but not against on-path attackers.		version unaware middleboxes, but not against on-path attackers.
	Once TLS has provided a key, the contents of regular QUIC packets		Once TLS has provided a key, the contents of regular QUIC packets
	immediately after any TLS messages have been sent are protected by		immediately after any TLS messages have been sent are protected by
	the AEAD selected by TLS.		the AEAD selected by TLS.
	The key, K, is either the client packet protection key		The key, K, is either the client packet protection key
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 10 ¶
	The associated data, A, for the AEAD is the contents of the QUIC		The associated data, A, for the AEAD is the contents of the QUIC
	header, starting from the flags octet in either the short or long		header, starting from the flags octet in either the short or long
	header.		header.
	The input plaintext, P, for the AEAD is the content of the QUIC frame		The input plaintext, P, for the AEAD is the content of the QUIC frame
	following the header, as described in [QUIC-TRANSPORT].		following the header, as described in [QUIC-TRANSPORT].
	The output ciphertext, C, of the AEAD is transmitted in place of P.		The output ciphertext, C, of the AEAD is transmitted in place of P.
	Prior to TLS providing keys, no record protection is performed and
	the plaintext, P, is transmitted unmodified.
	5.4. Packet Numbers		5.4. Packet Numbers
	QUIC has a single, contiguous packet number space. In comparison,		QUIC has a single, contiguous packet number space. In comparison,
	TLS restarts its sequence number each time that record protection		TLS restarts its sequence number each time that record protection
	keys are changed. The sequence number restart in TLS ensures that a		keys are changed. The sequence number restart in TLS ensures that a
	compromise of the current traffic keys does not allow an attacker to		compromise of the current traffic keys does not allow an attacker to
	truncate the data that is sent after a key update by sending		truncate the data that is sent after a key update by sending
	additional packets under the old key (causing new packets to be		additional packets under the old key (causing new packets to be
	discarded).		discarded).
	skipping to change at page 20, line 35 ¶		skipping to change at page 20, line 35 ¶
	protected packets use the QUIC long header, they do not use the		protected packets use the QUIC long header, they do not use the
	KEY_PHASE bit to select the correct keys (see Section 6.1.1).		KEY_PHASE bit to select the correct keys (see Section 6.1.1).
	Once the connection is fully enabled, the KEY_PHASE bit allows a		Once the connection is fully enabled, the KEY_PHASE bit allows a
	recipient to detect a change in keying material without necessarily		recipient to detect a change in keying material without necessarily
	needing to receive the first packet that triggered the change. An		needing to receive the first packet that triggered the change. An
	endpoint that notices a changed KEY_PHASE bit can update keys and		endpoint that notices a changed KEY_PHASE bit can update keys and
	decrypt the packet that contains the changed bit, see Section 6.2.		decrypt the packet that contains the changed bit, see Section 6.2.
	The KEY_PHASE bit is included as the 0x20 bit of the QUIC short		The KEY_PHASE bit is included as the 0x20 bit of the QUIC short
	header, or is determined by the packet type from the long header (a		header.
	type of 0x06 indicates a key phase of 0, 0x07 indicates key phase 1).
	Transitions between keys during the handshake are complicated by the		Transitions between keys during the handshake are complicated by the
	need to ensure that TLS handshake messages are sent with the correct		need to ensure that TLS handshake messages are sent with the correct
	packet protection.		packet protection.
	6.1. Packet Protection for the TLS Handshake		6.1. Packet Protection for the TLS Handshake
	The initial exchange of packets are sent using a cleartext packet		The initial exchange of packets that carry the TLS handshake are
	type and AEAD-protected using the cleartext key generated as		AEAD-protected using the handshake secrets generated as described in
	described in Section 5.2.1. All TLS handshake messages up to the TLS		Section 5.2.1. All TLS handshake messages up to the TLS Finished
	Finished message sent by either endpoint use cleartext packets.		message sent by either endpoint use packets protected with handshake
			keys.
	Any TLS handshake messages that are sent after completing the TLS		Any TLS handshake messages that are sent after completing the TLS
	handshake do not need special packet protection rules. Packets		handshake do not need special packet protection rules. Packets
	containing these messages use the packet protection keys that are		containing these messages use the packet protection keys that are
	current at the time of sending (or retransmission).		current at the time of sending (or retransmission).
	Like the client, a server MUST send retransmissions of its		Like the client, a server MUST send retransmissions of its
	unprotected handshake messages or acknowledgments for unprotected		unprotected handshake messages or acknowledgments for unprotected
	handshake messages sent by the client in cleartext packets.		handshake messages sent by the client in packets protected with
			handshake keys.
	6.1.1. Initial Key Transitions		6.1.1. Initial Key Transitions
	Once the TLS handshake is complete, keying material is exported from		Once the TLS handshake is complete, keying material is exported from
	TLS and used to protect QUIC packets.		TLS and used to protect QUIC packets.
	Packets protected with 1-RTT keys initially have a KEY_PHASE bit set		Packets protected with 1-RTT keys initially have a KEY_PHASE bit set
	to 0. This bit inverts with each subsequent key update (see		to 0. This bit inverts with each subsequent key update (see
	Section 6.2).		Section 6.2).
	If the client sends 0-RTT data, it uses the 0-RTT packet type. The		If the client sends 0-RTT data, it uses the 0-RTT packet type. The
	packet that contains the TLS EndOfEarlyData and Finished messages are		packet that contains the TLS EndOfEarlyData and Finished messages are
	sent in cleartext packets.		sent in packets protected with handshake keys.
	Using distinct packet types during the handshake for handshake		Using distinct packet types during the handshake for handshake
	messages, 0-RTT data, and 1-RTT data ensures that the server is able		messages, 0-RTT data, and 1-RTT data ensures that the server is able
	to distinguish between the different keys used to remove packet		to distinguish between the different keys used to remove packet
	protection. All of these packets can arrive concurrently at a		protection. All of these packets can arrive concurrently at a
	server.		server.
	A server might choose to retain 0-RTT packets that arrive before a		A server might choose to retain 0-RTT packets that arrive before a
	TLS ClientHello. The server can then use those packets once the		TLS ClientHello. The server can then use those packets once the
	ClientHello arrives. However, the potential for denial of service		ClientHello arrives. However, the potential for denial of service
	skipping to change at page 21, line 51 ¶		skipping to change at page 21, line 52 ¶
	6.1.2. Retransmission and Acknowledgment of Unprotected Packets		6.1.2. Retransmission and Acknowledgment of Unprotected Packets
	TLS handshake messages from both client and server are critical to		TLS handshake messages from both client and server are critical to
	the key exchange. The contents of these messages determines the keys		the key exchange. The contents of these messages determines the keys
	used to protect later messages. If these handshake messages are		used to protect later messages. If these handshake messages are
	included in packets that are protected with these keys, they will be		included in packets that are protected with these keys, they will be
	indecipherable to the recipient.		indecipherable to the recipient.
	Even though newer keys could be available when retransmitting,		Even though newer keys could be available when retransmitting,
	retransmissions of these handshake messages MUST be sent in cleartext		retransmissions of these handshake messages MUST be sent in packets
	packets. An endpoint MUST generate ACK frames for these messages and		protected with handshake keys. An endpoint MUST generate ACK frames
	send them in cleartext packets.		for these messages and send them in packets protected with handshake
			keys.
	A HelloRetryRequest handshake message might be used to reject an		A HelloRetryRequest handshake message might be used to reject an
	initial ClientHello. A HelloRetryRequest handshake message is sent		initial ClientHello. A HelloRetryRequest handshake message is sent
	in a Server Stateless Retry packet; any second ClientHello that is		in a Server Stateless Retry packet; any second ClientHello that is
	sent in response uses a Client Initial packet type. Neither packet		sent in response uses a Client Initial packet type. Neither packet
	is protected. This is natural, because no new keying material will		is protected. This is natural, because no new keying material will
	be available when these messages need to be sent. Upon receipt of a		be available when these messages need to be sent. Upon receipt of a
	HelloRetryRequest, a client SHOULD cease any transmission of 0-RTT		HelloRetryRequest, a client SHOULD cease any transmission of 0-RTT
	data; 0-RTT data will only be discarded by any server that sends a		data; 0-RTT data will only be discarded by any server that sends a
	HelloRetryRequest.		HelloRetryRequest.
	skipping to change at page 29, line 11 ¶		skipping to change at page 29, line 11 ¶
	certificate chain.		certificate chain.
	Stream 0 is exempt from the connection-level flow control window.		Stream 0 is exempt from the connection-level flow control window.
	Consequently, there is no need to signal being blocked on flow		Consequently, there is no need to signal being blocked on flow
	control.		control.
	Similarly, there is no need to increase the number of allowed streams		Similarly, there is no need to increase the number of allowed streams
	until the handshake completes.		until the handshake completes.
	8.1.4. Denial of Service with Unprotected Packets		8.1.4. Handshake Failures
			The "CONNECTION_CLOSE" frame MAY be sent by either endpoint in a
			Handshake packet. This allows an endpoint to signal a fatal error
			with connection establishment. A "STREAM" frame carrying a TLS alert
			MAY be included in the same packet.
			8.1.5. Denial of Service with Unprotected Packets
	Accepting unprotected - specifically unauthenticated - packets		Accepting unprotected - specifically unauthenticated - packets
	presents a denial of service risk to endpoints. An attacker that is		presents a denial of service risk to endpoints. An attacker that is
	able to inject unprotected packets can cause a recipient to drop even		able to inject unprotected packets can cause a recipient to drop even
	protected packets with a matching sequence number. The spurious		protected packets with a matching sequence number. The spurious
	packet shadows the genuine packet, causing the genuine packet to be		packet shadows the genuine packet, causing the genuine packet to be
	ignored as redundant.		ignored as redundant.
	Once the TLS handshake is complete, both peers MUST ignore		Once the TLS handshake is complete, both peers MUST ignore
	unprotected packets. From that point onward, unprotected messages		unprotected packets. From that point onward, unprotected messages
	skipping to change at page 30, line 24 ¶		skipping to change at page 30, line 35 ¶
	Due to reordering and loss, protected packets might be received by an		Due to reordering and loss, protected packets might be received by an
	endpoint before the final TLS handshake messages are received. A		endpoint before the final TLS handshake messages are received. A
	client will be unable to decrypt 1-RTT packets from the server,		client will be unable to decrypt 1-RTT packets from the server,
	whereas a server will be able to decrypt 1-RTT packets from the		whereas a server will be able to decrypt 1-RTT packets from the
	client.		client.
	Packets protected with 1-RTT keys MAY be stored and later decrypted		Packets protected with 1-RTT keys MAY be stored and later decrypted
	and used once the handshake is complete. A server MUST NOT use 1-RTT		and used once the handshake is complete. A server MUST NOT use 1-RTT
	protected packets before verifying either the client Finished message		protected packets before verifying either the client Finished message
	or - in the case that the server has chosen to use a pre-shared key -		or - in the case that the server has chosen to use a pre-shared key -
	the pre-shared key binder (see Section 4.2.8 of		the pre-shared key binder (see Section 4.2.8 of [TLS13]). Verifying
	[I-D.ietf-tls-tls13]). Verifying these values provides the server		these values provides the server with an assurance that the
	with an assurance that the ClientHello has not been modified.		ClientHello has not been modified.
	A server could receive packets protected with 0-RTT keys prior to		A server could receive packets protected with 0-RTT keys prior to
	receiving a TLS ClientHello. The server MAY retain these packets for		receiving a TLS ClientHello. The server MAY retain these packets for
	later decryption in anticipation of receiving a ClientHello.		later decryption in anticipation of receiving a ClientHello.
	Receiving and verifying the TLS Finished message is critical in		Receiving and verifying the TLS Finished message is critical in
	ensuring the integrity of the TLS handshake. A server MUST NOT use		ensuring the integrity of the TLS handshake. A server MUST NOT use
	protected packets from the client prior to verifying the client		protected packets from the client prior to verifying the client
	Finished message if its response depends on client authentication.		Finished message if its response depends on client authentication.
	skipping to change at page 32, line 6 ¶		skipping to change at page 32, line 16 ¶
	QUIC uses TLS without modification. Therefore, it is possible to use		QUIC uses TLS without modification. Therefore, it is possible to use
	a pre-shared key that was established in a TLS handshake over TCP to		a pre-shared key that was established in a TLS handshake over TCP to
	enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key		enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key
	that can be used to enable 0-RTT in TCP.		that can be used to enable 0-RTT in TCP.
	All the restrictions on the use of 0-RTT apply, with the exception of		All the restrictions on the use of 0-RTT apply, with the exception of
	the ALPN label, which MUST only change to a label that is explicitly		the ALPN label, which MUST only change to a label that is explicitly
	designated as being compatible. The client indicates which ALPN		designated as being compatible. The client indicates which ALPN
	label it has chosen by placing that ALPN label first in the ALPN		label it has chosen by placing that ALPN label first in the ALPN
	extension.		extension. In order to be usable for 0-RTT, the NewSessionTicket
			MUST contain the "max_early_data" extension with the value
			0xffffffff; the amount of data which the client can send in 0-RTT is
			controlled by the "initial_max_data" transport parameter supplied by
			the server. A client MUST treat receipt of a NewSessionTicket that
			contains a "max_early_data" extension with any other value as a
			connection error of type PROTOCOL_VIOLATION.
	The certificate that the server uses MUST be considered valid for		The certificate that the server uses MUST be considered valid for
	both connections, which will use different protocol stacks and could		both connections, which will use different protocol stacks and could
	use different port numbers. For instance, HTTP/1.1 and HTTP/2		use different port numbers. For instance, HTTP/1.1 and HTTP/2
	operate over TLS and TCP, whereas QUIC operates over UDP.		operate over TLS and TCP, whereas QUIC operates over UDP.
	Source address validation is not completely portable between		Source address validation is not completely portable between
	different protocol stacks. Even if the source IP address remains		different protocol stacks. Even if the source IP address remains
	constant, the port number is likely to be different. Packet		constant, the port number is likely to be different. Packet
	reflection attacks are still possible in this situation, though the		reflection attacks are still possible in this situation, though the
	skipping to change at page 34, line 33 ¶		skipping to change at page 35, line 4 ¶
	| 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 |		| 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 |
	| | | alert | |		| | | alert | |
	| | | | |		| | | | |
	| 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS | Section 11 |		| 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS | Section 11 |
	| | | alert | |		| | | alert | |
	+-------+---------------------------+---------------+---------------+		+-------+---------------------------+---------------+---------------+
	Table 1: QUIC Transport Error Codes for TLS		Table 1: QUIC Transport Error Codes for TLS
	13. References		13. References
	13.1. Normative References		13.1. Normative References
			[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
			Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
			<https://www.rfc-editor.org/info/rfc5116>.
	[FIPS180] Department of Commerce, National., "NIST FIPS 180-4,		[FIPS180] Department of Commerce, National., "NIST FIPS 180-4,
	Secure Hash Standard", March 2012,		Secure Hash Standard", March 2012,
	<http://csrc.nist.gov/publications/fips/fips180-4/		<http://csrc.nist.gov/publications/fips/fips180-4/
	fips-180-4.pdf>.		fips-180-4.pdf>.
	[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
	July 2017.
	[QUIC-TRANSPORT]		[QUIC-TRANSPORT]
	Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", draft-ietf-quic-		Multiplexed and Secure Transport", draft-ietf-quic-
	transport-07 (work in progress), October 2017.		transport-00 (work in progress), December 2017.
	[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>.
	[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
	<https://www.rfc-editor.org/info/rfc5116>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,		DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/info/rfc5869>.		<https://www.rfc-editor.org/info/rfc5869>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] 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>.
			[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>.
	[TLS-REGISTRIES]		[TLS-REGISTRIES]
	Salowey, J. and S. Turner, "D/TLS IANA Registry Updates",		Salowey, J. and S. Turner, "IANA Registry Updates for TLS
	draft-ietf-tls-iana-registry-updates-01 (work in		and DTLS", draft-ietf-tls-iana-registry-updates-02 (work
	progress), April 2017.		in progress), October 2017.
			[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", draft-ietf-tls-tls13-22 (work in progress),
			November 2017.
	13.2. Informative References		13.2. Informative References
	[AEBounds]		[AEBounds]
	Luykx, A. and K. Paterson, "Limits on Authenticated		Luykx, A. and K. Paterson, "Limits on Authenticated
	Encryption Use in TLS", March 2016,		Encryption Use in TLS", March 2016,
	<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.		<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
	[QUIC-HTTP]		[QUIC-HTTP]
	Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over		Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
	QUIC", draft-ietf-quic-http-07 (work in progress), October		QUIC", draft-ietf-quic-http-00 (work in progress),
	2017.		December 2017.
	[QUIC-RECOVERY]		[QUIC-RECOVERY]
	Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection		Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
	and Congestion Control", draft-ietf-quic-recovery-07 (work		and Congestion Control", draft-ietf-quic-recovery-00 (work
	in progress), October 2017.		in progress), December 2017.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	skipping to change at page 36, line 22 ¶		skipping to change at page 36, line 43 ¶
	(TLS) Cached Information Extension", RFC 7924,		(TLS) Cached Information Extension", RFC 7924,
	DOI 10.17487/RFC7924, July 2016,		DOI 10.17487/RFC7924, July 2016,
	<https://www.rfc-editor.org/info/rfc7924>.		<https://www.rfc-editor.org/info/rfc7924>.
	13.3. URIs		13.3. URIs
	[1] https://mailarchive.ietf.org/arch/search/?email_list=quic		[1] https://mailarchive.ietf.org/arch/search/?email_list=quic
	[2] https://github.com/quicwg		[2] https://github.com/quicwg
	[3] https://github.com/quicwg/base-drafts/labels/tls		[3] https://github.com/quicwg/base-drafts/labels/-tls
	Appendix A. Contributors		Appendix A. Contributors
	Ryan Hamilton was originally an author of this specification.		Ryan Hamilton was originally an author of this specification.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	This document has benefited from input from Dragana Damjanovic,		This document has benefited from input from Dragana Damjanovic,
	Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric		Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric
	Rescorla, Ian Swett, and many others.		Rescorla, Ian Swett, and many others.
End of changes. 63 change blocks.
	131 lines changed or deleted		152 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/