draft-ietf-quic-tls-08.txt		draft-ietf-quic-tls-09.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: June 8, 2018 sn3rd		Expires: August 1, 2018 sn3rd
	December 5, 2017		January 28, 2018
	Using Transport Layer Security (TLS) to Secure QUIC		Using Transport Layer Security (TLS) to Secure QUIC
	draft-ietf-quic-tls-08		draft-ietf-quic-tls-09
	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
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 June 8, 2018.		This Internet-Draft will expire on August 1, 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
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	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. Handshake Secrets . . . . . . . . . . . . . . . . . . 15		5.2.1. Handshake Secrets . . . . . . . . . . . . . . . . . . 15
	5.2.2. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 16		5.2.2. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 15
	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 . . . . . . . . . . . . . . . . . . . . . 18
	5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19		5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19
	5.6. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 20		5.6. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 19
	6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20		6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 19
	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 . . . . . . . . . . . . . . . 20
	6.1.2. Retransmission and Acknowledgment of Unprotected		6.1.2. Retransmission and Acknowledgment of Unprotected
	Packets . . . . . . . . . . . . . . . . . . . . . . . 21		Packets . . . . . . . . . . . . . . . . . . . . . . . 21
	6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 22		6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 22
	7. Client Address Validation . . . . . . . . . . . . . . . . . . 24		7. Client Address Validation . . . . . . . . . . . . . . . . . . 24
	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
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33		10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33
	11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33		11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	13.1. Normative References . . . . . . . . . . . . . . . . . . 35		13.1. Normative References . . . . . . . . . . . . . . . . . . 35
	13.2. Informative References . . . . . . . . . . . . . . . . . 36		13.2. Informative References . . . . . . . . . . . . . . . . . 36
	13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36		13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 37		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 37
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37
	C.1. Since draft-ietf-quic-tls-06 . . . . . . . . . . . . . . 37		C.1. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 37
	C.2. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 37		C.2. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 37
	C.3. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37		C.3. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 37
	C.4. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 37		C.4. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37
	C.5. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 37		C.5. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 37
	C.6. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 37		C.6. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 37
	C.7. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 38		C.7. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 37
	C.8. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 38		C.8. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 38
			C.9. 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 [TLS13]. TLS 1.3 provides		Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides
	critical latency improvements for connection establishment over		critical latency improvements for connection establishment over
	previous versions. Absent packet loss, most new connections can be		previous versions. Absent packet loss, most new connections can be
	established and secured within a single round trip; on subsequent		established and secured within a single round trip; on subsequent
	connections between the same client and server, the client can often		connections between the same client and server, the client can often
	skipping to change at page 15, line 25 ¶		skipping to change at page 15, line 25 ¶
	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. Handshake Secrets		5.2.1. Handshake Secrets
	Packets that carry the TLS handshake (Initial, Retry, and Handshake)		Packets that carry the TLS handshake (Initial, Retry, and Handshake)
	are protected with secrets derived from the connection ID used in the		are protected with secrets derived from the connection ID used in the
	client's Initial packet. Specifically:		client's Initial packet. Specifically:
	quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639		quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639
	handshake_secret = HKDF-Extract(quic_version_1_salt,		handshake_secret = HKDF-Extract(quic_version_1_salt,
	client_connection_id)		client_connection_id)
	client_handshake_secret =		client_handshake_secret =
	HKDF-Expand-Label(handshake_secret,		QHKDF-Expand(handshake_secret, "client hs", Hash.length)
	"QUIC client handshake secret",		server_handshake_secret =
	"", Hash.length)		QHKDF-Expand(handshake_secret, "server hs", Hash.length)
	server_handshake_secret =
	HKDF-Expand-Label(handshake_secret,
	"QUIC server handshake secret",
	"", Hash.length)
	The HKDF for the handshake secrets and keys derived from them uses		The HKDF for the handshake secrets and keys derived from them uses
	the SHA-256 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 handshake		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.
	The secret is exported from TLS using the exporter label "EXPORTER-		The secret is exported from TLS using the exporter label "EXPORTER-
	QUIC 0-RTT Secret" and an empty context. The size of the secret MUST		QUIC 0rtt" and an empty context. The size of the secret MUST be the
	be the size of the hash output for the PRF hash function negotiated		size of the hash output for the PRF hash function negotiated by TLS.
	by TLS. This uses the TLS early_exporter_secret. The QUIC 0-RTT		This uses the TLS early_exporter_secret. The QUIC 0-RTT secret is
	secret is only used for protection of packets sent by the client.		only used for protection of packets sent by the client.
	client_0rtt_secret		client_0rtt_secret
	= TLS-Exporter("EXPORTER-QUIC 0-RTT Secret"		= TLS-Exporter("EXPORTER-QUIC 0rtt", "", Hash.length)
	"", Hash.length)
	5.2.3. 1-RTT Secrets		5.2.3. 1-RTT Secrets
	1-RTT keys are used by both client and server after the TLS handshake		1-RTT keys are used by both client and server after the TLS handshake
	completes. There are two secrets used at any time: one is used to		completes. There are two secrets used at any time: one is used to
	derive packet protection keys for packets sent by the client, the		derive packet protection keys for packets sent by the client, the
	other for packet protection keys on packets sent by the server.		other for packet protection keys on packets sent by the server.
	The initial client packet protection secret is exported from TLS		The initial client packet protection secret is exported from TLS
	using the exporter label "EXPORTER-QUIC client 1-RTT Secret"; the		using the exporter label "EXPORTER-QUIC client 1rtt"; the initial
	initial server packet protection secret uses the exporter label		server packet protection secret uses the exporter label "EXPORTER-
	"EXPORTER-QUIC server 1-RTT Secret". Both exporters use an empty		QUIC server 1rtt". Both exporters use an empty context. The size of
	context. The size of the secret MUST be the size of the hash output		the secret MUST be the size of the hash output for the PRF hash
	for the PRF hash function negotiated by TLS.		function negotiated by TLS.
	client_pp_secret_0		client_pp_secret_0 =
	= TLS-Exporter("EXPORTER-QUIC client 1-RTT Secret"		TLS-Exporter("EXPORTER-QUIC client 1rtt", "", Hash.length)
	"", Hash.length)		server_pp_secret_0 =
	server_pp_secret_0		TLS-Exporter("EXPORTER-QUIC server 1rtt", "", Hash.length)
	= TLS-Exporter("EXPORTER-QUIC server 1-RTT Secret"
	"", 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 [TLS13].		the QHKDF-Expand function. The QHKDF-Expand function is similar in
	HKDF-Expand-Label uses the PRF hash function negotiated by TLS. The		definition to HKDF-Expand-Label defined in Section 7.1 of [TLS13],
			but it has a different base label and omits the hash argument.
			QHKDF-Expand uses the PRF hash function negotiated by TLS. The
	replacement secret is derived using the existing Secret, a Label of		replacement secret is derived using the existing Secret, a Label of
	"QUIC client 1-RTT Secret" for the client and "QUIC server 1-RTT		"client 1rtt" for the client and "server 1rtt" for the server, and
	Secret" for the server, an empty HashValue, and the same output		the same output Length as the PRF hash function selected by TLS.
	Length as the hash function selected by TLS for its PRF.
	client_pp_secret_<N+1>		client_pp_secret_<N+1> =
	= HKDF-Expand-Label(client_pp_secret_<N>,		QHKDF-Expand(client_pp_secret_<N>, "client 1rtt", Hash.length)
	"QUIC client 1-RTT Secret",		server_pp_secret_<N+1> =
	"", Hash.length)		QHKDF-Expand(server_pp_secret_<N>, "server 1rtt", Hash.length)
	server_pp_secret_<N+1>
	= HKDF-Expand-Label(server_pp_secret_<N>,
	"QUIC server 1-RTT Secret",
	"", Hash.length)
	This allows for a succession of new secrets to be created as needed.		This allows for a succession of new secrets to be created as needed.
	HKDF-Expand-Label uses HKDF-Expand [RFC5869] with a specially		HKDF-Expand-Label uses HKDF-Expand [RFC5869] as shown:
	formatted info parameter, as shown:
	HKDF-Expand-Label(Secret, Label, HashValue, Length) =		QHKDF-Expand(Secret, Label, Length) =
	HKDF-Expand(Secret, HkdfLabel, Length)		HKDF-Expand(Secret, QuicHkdfLabel, Length)
	Where HkdfLabel is specified as:		Where the info parameter, QuicHkdfLabel, is specified as:
	struct {		struct {
	uint16 length = Length;		uint16 length = Length;
	opaque label<10..255> = "tls13 " + Label;		opaque label<6..255> = "QUIC " + Label;
	uint8 hashLength; // Always 0		uint8 hashLength = 0;
	} HkdfLabel;		} QuicHkdfLabel;
	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		"QUIC client 1rtt" || 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 [TLS13], using different		expansion as defined in Section 7.3 of [TLS13], using different
	values for the input secret. QUIC uses the AEAD function negotiated		values for the input secret and labels. QUIC uses the AEAD function
	by TLS.		negotiated 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 and server
	and server_pp_secret respectively. The length of the output is		1-RTT secrets (client_pp_secret_<i> and server_pp_secret_<i>)
	determined by the requirements of the AEAD function selected by TLS.		respectively. The length of the output is determined by the
	All ciphersuites currently used for QUIC have a 16-byte		requirements of the AEAD function selected by TLS. All ciphersuites
	authentication tag and produce an ouput 16 bytes larger than their		currently used for QUIC have a 16-byte authentication tag and produce
	input. The key length is the AEAD key size. As defined in		an ouput 16 bytes larger than their input. The key length is the
	Section 5.3 of [TLS13], the IV length is the larger of 8 or N_MIN		AEAD key size. As defined in Section 5.3 of [TLS13], the IV length
	(see Section 4 of [AEAD]; all ciphersuites defined in [TLS13] have		is the larger of 8 or N_MIN (see Section 4 of [AEAD]; all
	N_MIN set to 12). For any secret S, the corresponding key and IV are		ciphersuites defined in [TLS13] have N_MIN set to 12). For any
	derived as shown below:		secret S, the corresponding key and IV are derived as shown below:
	key = HKDF-Expand-Label(S, "key", "", key_length)		key = QHKDF-Expand(S, "key", key_length)
	iv = HKDF-Expand-Label(S, "iv", "", iv_length)		iv = QHKDF-Expand(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) [AEAD]		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 [AEAD]. Cleartext		packets are protected with an AEAD algorithm [AEAD]. Prior to
	packets are protected with AEAD_AES_128_GCM and a key derived from		establishing a shared secret, packets are protected with
	the client's connection ID (see Section 5.2.1). This provides		AEAD_AES_128_GCM and a key derived from the client's connection ID
	protection against off-path attackers and robustness against QUIC		(see Section 5.2.1). This provides protection against off-path
	version unaware middleboxes, but not against on-path attackers.		attackers and robustness against QUIC 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
	(client_pp_key_n) or the server packet protection key		(client_pp_key_<i>) or the server packet protection key
	(server_pp_key_n), derived as defined in Section 5.2.		(server_pp_key_<i>), derived as defined in Section 5.2.
	The nonce, N, is formed by combining the packet protection IV (either		The nonce, N, is formed by combining the packet protection IV (either
	client_pp_iv_n or server_pp_iv_n) with the packet number. The 64		client_pp_iv_<i> or server_pp_iv_<i>) with the packet number. The 64
	bits of the reconstructed QUIC packet number in network byte order is		bits of the reconstructed QUIC packet number in network byte order is
	left-padded with zeros to the size of the IV. The exclusive OR of		left-padded with zeros to the size of the IV. The exclusive OR of
	the padded packet number and the IV forms the AEAD nonce.		the padded packet number and the IV forms the AEAD nonce.
	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].
	skipping to change at page 20, line 7 ¶		skipping to change at page 19, line 39 ¶
	Section 6.2). Similarly, a packet that appears to trigger a key		Section 6.2). Similarly, a packet that appears to trigger a key
	update, but cannot be unprotected successfully MUST be discarded.		update, but cannot be unprotected successfully MUST be discarded.
	Failure to unprotect a packet does not necessarily indicate the		Failure to unprotect a packet does not necessarily indicate the
	existence of a protocol error in a peer or an attack. The truncated		existence of a protocol error in a peer or an attack. The truncated
	packet number encoding used in QUIC can cause packet numbers to be		packet number encoding used in QUIC can cause packet numbers to be
	decoded incorrectly if they are delayed significantly.		decoded incorrectly if they are delayed significantly.
	5.6. Packet Number Gaps		5.6. Packet Number Gaps
	Section 7.5.1.1 of [QUIC-TRANSPORT] also requires a secret to compute		Section 7.7.1.1 of [QUIC-TRANSPORT] also requires a secret to compute
	packet number gaps on connection ID transitions. That secret is		packet number gaps on connection ID transitions. That secret is
	computed as:		computed as:
	packet_number_secret		packet_number_secret =
	= TLS-Exporter("EXPORTER-QUIC Packet Number Secret"		TLS-Exporter("EXPORTER-QUIC packet number", "", Hash.length)
	"", Hash.length)
	6. Key Phases		6. Key Phases
	As TLS reports the availability of 0-RTT and 1-RTT keys, new keying		As TLS reports the availability of 0-RTT and 1-RTT keys, new keying
	material can be exported from TLS and used for QUIC packet		material can be exported from TLS and used for QUIC packet
	protection. At each transition during the handshake a new secret is		protection. At each transition during the handshake a new secret is
	exported from TLS and packet protection keys are derived from that		exported from TLS and packet protection keys are derived from that
	secret.		secret.
	Every time that a new set of keys is used for protecting outbound		Every time that a new set of keys is used for protecting outbound
	skipping to change at page 22, line 10 ¶		skipping to change at page 21, line 41 ¶
	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 packets		retransmissions of these handshake messages MUST be sent in packets
	protected with handshake keys. An endpoint MUST generate ACK frames		protected with handshake keys. An endpoint MUST generate ACK frames
	for these messages and send them in packets protected with handshake		for these messages and send them in packets protected with handshake
	keys.		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 Retry packet; any second ClientHello that is sent in response
	sent in response uses a Client Initial packet type. Neither packet		uses a Initial packet type. These packets are only protected with a
	is protected. This is natural, because no new keying material will		predictable key (see Section 5.2.1). This is natural, because no
	be available when these messages need to be sent. Upon receipt of a		shared secret will be available when these messages need to be sent.
	HelloRetryRequest, a client SHOULD cease any transmission of 0-RTT		Upon receipt of a HelloRetryRequest, a client SHOULD cease any
	data; 0-RTT data will only be discarded by any server that sends a		transmission of 0-RTT data; 0-RTT data will only be discarded by any
	HelloRetryRequest.		server that sends a HelloRetryRequest.
	The packet type ensures that protected packets are clearly		The packet type ensures that protected packets are clearly
	distinguished from unprotected packets. Loss or reordering might		distinguished from unprotected packets. Loss or reordering might
	cause unprotected packets to arrive once 1-RTT keys are in use,		cause unprotected packets to arrive once 1-RTT keys are in use,
	unprotected packets are easily distinguished from 1-RTT packets using		unprotected packets are easily distinguished from 1-RTT packets using
	the packet type.		the packet type.
	Once 1-RTT keys are available to an endpoint, it no longer needs the		Once 1-RTT keys are available to an endpoint, it no longer needs the
	TLS handshake messages that are carried in unprotected packets.		TLS handshake messages that are carried in unprotected packets.
	However, a server might need to retransmit its TLS handshake messages		However, a server might need to retransmit its TLS handshake messages
	skipping to change at page 25, line 37 ¶		skipping to change at page 25, line 28 ¶
	7.1.2. Sending HelloRetryRequest		7.1.2. Sending HelloRetryRequest
	A server does not need to maintain state for the connection when		A server does not need to maintain state for the connection when
	sending a HelloRetryRequest message. This might be necessary to		sending a HelloRetryRequest message. This might be necessary to
	avoid creating a denial of service exposure for the server. However,		avoid creating a denial of service exposure for the server. However,
	this means that information about the transport will be lost at the		this means that information about the transport will be lost at the
	server. This includes the stream offset of stream 0, the packet		server. This includes the stream offset of stream 0, the packet
	number that the server selects, and any opportunity to measure round		number that the server selects, and any opportunity to measure round
	trip time.		trip time.
	A server MUST send a TLS HelloRetryRequest in a Server Stateless		A server MUST send a TLS HelloRetryRequest in a Retry packet. Using
	Retry packet. Using a Server Stateless Retry packet causes the		a Retry packet causes the client to reset stream offsets. It also
	client to reset stream offsets. It also avoids the need for the		avoids the need for the server select an initial packet number, which
	server select an initial packet number, which would need to be		would need to be remembered so that subsequent packets could be
	remembered so that subsequent packets could be correctly numbered.		correctly numbered.
	A HelloRetryRequest message MUST NOT be split between multiple Server		A HelloRetryRequest message MUST NOT be split between multiple Retry
	Stateless Retry packets. This means that HelloRetryRequest is		packets. This means that HelloRetryRequest is subject to the same
	subject to the same size constraints as a ClientHello (see		size constraints as a ClientHello (see Section 4.4).
	Section 4.4).
			A client might send multiple Initial packets in response to loss. If
			a server sends a Retry packet in response to an Initial packet, it
			does not have to generate the same Retry packet each time.
			Variations in Retry packet, if used by a client, could lead to
			multiple connections derived from the same ClientHello. Reuse of the
			client nonce is not supported by TLS and could lead to security
			vulnerabilities. Clients that receive multiple Retry packets MUST
			use only one and discard the remainder.
	7.2. NewSessionTicket Address Validation		7.2. NewSessionTicket Address Validation
	The ticket in the TLS NewSessionTicket message allows a server to		The ticket in the TLS NewSessionTicket message allows a server to
	provide a client with a similar sort of token. When a client resumes		provide a client with a similar sort of token. When a client resumes
	a TLS connection - whether or not 0-RTT is attempted - it includes		a TLS connection - whether or not 0-RTT is attempted - it includes
	the ticket in the handshake message. As with the HelloRetryRequest		the ticket in the handshake message. As with the HelloRetryRequest
	cookie, the server includes the address validation token in the		cookie, the server includes the address validation token in the
	ticket. TLS provides the token it extracts from the session ticket		ticket. TLS provides the token it extracts from the session ticket
	to the transport when it asks whether source address validation is		to the transport when it asks whether source address validation is
	skipping to change at page 31, line 50 ¶		skipping to change at page 31, line 50 ¶
	quic_transport_parameters(26), (65535)		quic_transport_parameters(26), (65535)
	} ExtensionType;		} ExtensionType;
	The "extension_data" field of the quic_transport_parameters extension		The "extension_data" field of the quic_transport_parameters extension
	contains a value that is defined by the version of QUIC that is in		contains a value that is defined by the version of QUIC that is in
	use. The quic_transport_parameters extension carries a		use. The quic_transport_parameters extension carries a
	TransportParameters when the version of QUIC defined in		TransportParameters when the version of QUIC defined in
	[QUIC-TRANSPORT] is used.		[QUIC-TRANSPORT] is used.
	The quic_transport_parameters extension is carried in the ClientHello		The quic_transport_parameters extension is carried in the ClientHello
	and the EncryptedExtensions messages during the handshake. The		and the EncryptedExtensions messages during the handshake.
	extension MAY be included in a NewSessionTicket message.
	9.3. Priming 0-RTT		9.3. Priming 0-RTT
	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
	skipping to change at page 35, line 18 ¶		skipping to change at page 35, line 18 ¶
	<https://www.rfc-editor.org/info/rfc5116>.		<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>.
	[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-00 (work in progress), December 2017.		transport-09 (work in progress), January 2018.
	[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>.
	[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>.
	skipping to change at page 35, line 41 ¶		skipping to change at page 35, line 41 ¶
	"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		[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>.
	[TLS-REGISTRIES]		[TLS-REGISTRIES]
	Salowey, J. and S. Turner, "IANA Registry Updates for TLS		Salowey, J. and S. Turner, "IANA Registry Updates for TLS
	and DTLS", draft-ietf-tls-iana-registry-updates-02 (work		and DTLS", draft-ietf-tls-iana-registry-updates-03 (work
	in progress), October 2017.		in progress), January 2018.
	[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-22 (work in progress),		Version 1.3", draft-ietf-tls-tls13-23 (work in progress),
	November 2017.		January 2018.
	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-00 (work in progress),		QUIC", draft-ietf-quic-http-09 (work in progress), January
	December 2017.		2018.
	[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-00 (work		and Congestion Control", draft-ietf-quic-recovery-09 (work
	in progress), December 2017.		in progress), January 2018.
	[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 37, line 18 ¶		skipping to change at page 37, line 18 ¶
	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.
	Appendix C. Change Log		Appendix C. Change Log
	*RFC Editor's Note:* Please remove this section prior to		*RFC Editor's Note:* Please remove this section prior to
	publication of a final version of this document.		publication of a final version of this document.
	Issue and pull request numbers are listed with a leading octothorp.		Issue and pull request numbers are listed with a leading octothorp.
	C.1. Since draft-ietf-quic-tls-06		C.1. Since draft-ietf-quic-tls-08
	Nothing yet.		o Specify value for max_early_data_size to enable 0-RTT (#942)
	C.2. Since draft-ietf-quic-tls-05		o Update key derivation function (#1003, #1004)
			C.2. Since draft-ietf-quic-tls-07
			o Handshake errors can be reported with CONNECTION_CLOSE (#608,
			#891)
			C.3. Since draft-ietf-quic-tls-05
	No significant changes.		No significant changes.
	C.3. Since draft-ietf-quic-tls-04		C.4. Since draft-ietf-quic-tls-04
	o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)		o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
	C.4. Since draft-ietf-quic-tls-03		C.5. Since draft-ietf-quic-tls-03
	No significant changes.		No significant changes.
	C.5. Since draft-ietf-quic-tls-02		C.6. Since draft-ietf-quic-tls-02
	o Updates to match changes in transport draft		o Updates to match changes in transport draft
	C.6. Since draft-ietf-quic-tls-01		C.7. Since draft-ietf-quic-tls-01
	o Use TLS alerts to signal TLS errors (#272, #374)		o Use TLS alerts to signal TLS errors (#272, #374)
	o Require ClientHello to fit in a single packet (#338)		o Require ClientHello to fit in a single packet (#338)
	o The second client handshake flight is now sent in the clear (#262,		o The second client handshake flight is now sent in the clear (#262,
	#337)		#337)
	o The QUIC header is included as AEAD Associated Data (#226, #243,		o The QUIC header is included as AEAD Associated Data (#226, #243,
	#302)		#302)
	skipping to change at page 38, line 4 ¶		skipping to change at page 38, line 11 ¶
	o The second client handshake flight is now sent in the clear (#262,		o The second client handshake flight is now sent in the clear (#262,
	#337)		#337)
	o The QUIC header is included as AEAD Associated Data (#226, #243,		o The QUIC header is included as AEAD Associated Data (#226, #243,
	#302)		#302)
	o Add interface necessary for client address validation (#275)		o Add interface necessary for client address validation (#275)
	o Define peer authentication (#140)		o Define peer authentication (#140)
	o Require at least TLS 1.3 (#138)		o Require at least TLS 1.3 (#138)
	o Define transport parameters as a TLS extension (#122)		o Define transport parameters as a TLS extension (#122)
	o Define handling for protected packets before the handshake		o Define handling for protected packets before the handshake
	completes (#39)		completes (#39)
	o Decouple QUIC version and ALPN (#12)		o Decouple QUIC version and ALPN (#12)
	C.7. Since draft-ietf-quic-tls-00		C.8. Since draft-ietf-quic-tls-00
	o Changed bit used to signal key phase		o Changed bit used to signal key phase
	o Updated key phase markings during the handshake		o Updated key phase markings during the handshake
	o Added TLS interface requirements section		o Added TLS interface requirements section
	o Moved to use of TLS exporters for key derivation		o Moved to use of TLS exporters for key derivation
	o Moved TLS error code definitions into this document		o Moved TLS error code definitions into this document
	C.8. Since draft-thomson-quic-tls-01		C.9. Since draft-thomson-quic-tls-01
	o Adopted as base for draft-ietf-quic-tls		o Adopted as base for draft-ietf-quic-tls
	o Updated authors/editors list		o Updated authors/editors list
	o Added status note		o Added status note
	Authors' Addresses		Authors' Addresses
	Martin Thomson (editor)		Martin Thomson (editor)
End of changes. 51 change blocks.
	130 lines changed or deleted		135 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/