Diff: draft-ietf-quic-tls-11.txt - draft-ietf-quic-tls-12.txt

	draft-ietf-quic-tls-11.txt	draft-ietf-quic-tls-12.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: October 19, 2018 sn3rd	Expires: November 23, 2018 sn3rd
	April 17, 2018	May 22, 2018

	Using Transport Layer Security (TLS) to Secure QUIC	Using Transport Layer Security (TLS) to Secure QUIC

	draft-ietf-quic-tls-11	draft-ietf-quic-tls-12

	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 October 19, 2018.	This Internet-Draft will expire on November 23, 2018.

	Copyright Notice	Copyright Notice

	Copyright (c) 2018 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

	skipping to change at page 2, line 47 ¶	skipping to change at page 2, line 47 ¶
	5.2. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15	5.2. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15
	5.3. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 16	5.3. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 16
	5.3.1. QHKDF-Expand . . . . . . . . . . . . . . . . . . . . 16	5.3.1. QHKDF-Expand . . . . . . . . . . . . . . . . . . . . 16
	5.3.2. Handshake Secrets . . . . . . . . . . . . . . . . . . 17	5.3.2. Handshake Secrets . . . . . . . . . . . . . . . . . . 17
	5.3.3. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 17	5.3.3. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 17
	5.3.4. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 18	5.3.4. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 18
	5.3.5. Updating 1-RTT Secrets . . . . . . . . . . . . . . . 18	5.3.5. Updating 1-RTT Secrets . . . . . . . . . . . . . . . 18
	5.3.6. Packet Protection Keys . . . . . . . . . . . . . . . 18	5.3.6. Packet Protection Keys . . . . . . . . . . . . . . . 18
	5.4. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 19	5.4. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 19
	5.5. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 20	5.5. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 20

	5.6. Receiving Protected Packets . . . . . . . . . . . . . . . 21	5.6. Packet Number Protection . . . . . . . . . . . . . . . . 21
	5.7. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 21	5.6.1. AES-Based Packet Number Protection . . . . . . . . . 22
	6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 21	5.6.2. ChaCha20-Based Packet Number Protection . . . . . . . 22
	6.1. Packet Protection for the TLS Handshake . . . . . . . . . 22	5.7. Receiving Protected Packets . . . . . . . . . . . . . . . 22
	6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 22	6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 23
		6.1. Packet Protection for the TLS Handshake . . . . . . . . . 23
		6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 24
	6.1.2. Retransmission and Acknowledgment of Unprotected	6.1.2. Retransmission and Acknowledgment of Unprotected

	Packets . . . . . . . . . . . . . . . . . . . . . . . 23	Packets . . . . . . . . . . . . . . . . . . . . . . . 24
	6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 24	6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 25
	7. Client Address Validation . . . . . . . . . . . . . . . . . . 25	7. Client Address Validation . . . . . . . . . . . . . . . . . . 27
	7.1. HelloRetryRequest Address Validation . . . . . . . . . . 26	7.1. HelloRetryRequest Address Validation . . . . . . . . . . 27
	7.1.1. Stateless Address Validation . . . . . . . . . . . . 26	7.1.1. Stateless Address Validation . . . . . . . . . . . . 28
	7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 27	7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 28
	7.2. NewSessionTicket Address Validation . . . . . . . . . . . 27	7.2. NewSessionTicket Address Validation . . . . . . . . . . . 29
	7.3. Address Validation Token Integrity . . . . . . . . . . . 28	7.3. Address Validation Token Integrity . . . . . . . . . . . 29
	8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 28	8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 29
	8.1. Unprotected Packets Prior to Handshake Completion . . . . 29	8.1. Unprotected Packets Prior to Handshake Completion . . . . 30
	8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 29	8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 31
	8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 29	8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 31
	8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 30	8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 31
	8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 31	8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 32
	8.1.5. Address Verification . . . . . . . . . . . . . . . . 31	8.1.5. Address Verification . . . . . . . . . . . . . . . . 32
	8.1.6. Denial of Service with Unprotected Packets . . . . . 31	8.1.6. Denial of Service with Unprotected Packets . . . . . 32
	8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 32	8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 33
	8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 32	8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 33
	9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 33	9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 34
	9.1. Protocol and Version Negotiation . . . . . . . . . . . . 33	9.1. Protocol and Version Negotiation . . . . . . . . . . . . 34
	9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 33	9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 34
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 34	10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 34	10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 35
	10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 34	10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 35
	11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 35	10.3. Packet Number Protection Analysis . . . . . . . . . . . 36
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35	11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 37
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	13.1. Normative References . . . . . . . . . . . . . . . . . . 36	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	13.2. Informative References . . . . . . . . . . . . . . . . . 37	13.1. Normative References . . . . . . . . . . . . . . . . . . 38
	13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 38	13.2. Informative References . . . . . . . . . . . . . . . . . 39
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 38	13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 38	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 40
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40
	C.1. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 38	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40
	C.2. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 38	C.1. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 41
	C.3. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 38	C.2. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 41
	C.4. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 38	C.3. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 41
	C.5. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 39	C.4. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 41
	C.6. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 39	C.5. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 41
	C.7. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 39	C.6. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 41
	C.8. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 39	C.7. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 41
	C.9. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 39	C.8. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 41
	C.10. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 39	C.9. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 41
	C.11. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 40	C.10. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40	C.11. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 42
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42

	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
	send application data immediately, that is, using a zero round trip	send application data immediately, that is, using a zero round trip

	skipping to change at page 17, line 21 ¶	skipping to change at page 17, line 21 ¶
	handshake_salt = 0x9c108f98520a5c5c32968e950e8a2c5fe06d6c38	handshake_salt = 0x9c108f98520a5c5c32968e950e8a2c5fe06d6c38
	handshake_secret =	handshake_secret =
	HKDF-Extract(handshake_salt, client_dst_connection_id)	HKDF-Extract(handshake_salt, client_dst_connection_id)

	client_handshake_secret =	client_handshake_secret =
	QHKDF-Expand(handshake_secret, "client hs", Hash.length)	QHKDF-Expand(handshake_secret, "client hs", Hash.length)
	server_handshake_secret =	server_handshake_secret =
	QHKDF-Expand(handshake_secret, "server hs", Hash.length)	QHKDF-Expand(handshake_secret, "server hs", Hash.length)

	The hash function for HKDF when deriving handshake secrets and keys	The hash function for HKDF when deriving handshake secrets and keys

	is SHA-256 [FIPS180]. The connection ID used with QHKDF-Expand is	is SHA-256 [SHA]. The connection ID used with QHKDF-Expand is the
	the connection ID chosen by the client.	connection ID chosen by the client.

	The handshake salt is a 20 octet sequence shown in the figure in	The handshake salt 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.

	Note: The Destination Connection ID is of arbitrary length, and it	Note: The Destination Connection ID is of arbitrary length, and it
	could be zero length if the server sends a Retry packet with a	could be zero length if the server sends a Retry packet with a

	skipping to change at page 19, line 18 ¶	skipping to change at page 19, line 18 ¶
	server are derived from the current generation of client and server	server are derived from the current generation of client and server
	1-RTT secrets (client_pp_secret<i> and server_pp_secret<i>)	1-RTT secrets (client_pp_secret<i> and server_pp_secret<i>)
	respectively.	respectively.

	The length of the QHKDF-Expand output is determined by the	The length of the QHKDF-Expand output is determined by the
	requirements of the AEAD function selected by TLS. The key length is	requirements of the AEAD function selected by TLS. The key length is
	the AEAD key size. As defined in Section 5.3 of [TLS13], the IV	the AEAD key size. As defined in Section 5.3 of [TLS13], the IV
	length is the larger of 8 or N_MIN (see Section 4 of [AEAD]; all	length is the larger of 8 or N_MIN (see Section 4 of [AEAD]; all
	ciphersuites defined in [TLS13] have N_MIN set to 12).	ciphersuites defined in [TLS13] have N_MIN set to 12).


	For any secret S, the AEAD key uses a label of "key", and the IV uses	The size of the packet protection key is determined by the packet
	a label of "iv":	protection algorithm, see Section 5.6.

		For any secret S, the AEAD key uses a label of "key", the IV uses a
		label of "iv", packet number encryption uses a label of "pn":

	key = QHKDF-Expand(S, "key", key_length)	key = QHKDF-Expand(S, "key", key_length)

	iv = QHKDF-Expand(S, "iv", iv_length)	iv = QHKDF-Expand(S, "iv", iv_length)
		pn_key = QHKDF-Expand(S, "pn", pn_key_length)

	Separate keys are derived for packet protection by clients and	Separate keys are derived for packet protection by clients and
	servers. Each endpoint uses the packet protection key of its peer to	servers. Each endpoint uses the packet protection key of its peer to
	remove packet protection. For example, client packet protection keys	remove packet protection. For example, client packet protection keys
	and IVs - which are also used by the server to remove the protection	and IVs - which are also used by the server to remove the protection
	added by a client - for AEAD_AES_128_GCM are derived from 1-RTT	added by a client - for AEAD_AES_128_GCM are derived from 1-RTT
	secrets as follows:	secrets as follows:

	client_pp_key<i> = QHKDF-Expand(client_pp_secret<i>, "key", 16)	client_pp_key<i> = QHKDF-Expand(client_pp_secret<i>, "key", 16)
	client_pp_iv<i> = QHKDF-Expand(client_pp_secret<i>, "iv", 12)	client_pp_iv<i> = QHKDF-Expand(client_pp_secret<i>, "iv", 12)

		client_pp_pn<i> = QHKDF-Expand(client_pp_secret<i>, "pn", 12)


	The QUIC record protection initially starts with keying material	The QUIC packet protection initially starts with keying material
	derived from handshake keys. For a client, when the TLS state	derived from handshake keys. For a client, when the TLS state
	machine reports that the ClientHello has been sent, 0-RTT keys can be	machine reports that the ClientHello has been sent, 0-RTT keys can be
	generated and installed for writing, if 0-RTT is available. Finally,	generated and installed for writing, if 0-RTT is available. Finally,
	the TLS state machine reports completion of the handshake and 1-RTT	the TLS state machine reports completion of the handshake and 1-RTT
	keys can be generated and installed for writing.	keys can be generated and installed for writing.

	5.4. QUIC AEAD Usage	5.4. 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.


		QUIC packets are protected prior to applying packet number encryption
		(Section 5.6). The unprotected packet number is part of the
		associated data (A). When removing packet protection, an endpoint
		first removes the protection from the packet number.

	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]. Prior to	packets are protected with an AEAD algorithm [AEAD]. Prior to
	establishing a shared secret, packets are protected with	establishing a shared secret, packets are protected with
	AEAD_AES_128_GCM and a key derived from the client's connection ID	AEAD_AES_128_GCM and a key derived from the client's connection ID
	(see Section 5.3.2). This provides protection against off-path	(see Section 5.3.2). This provides protection against off-path
	attackers and robustness against QUIC version unaware middleboxes,	attackers and robustness against QUIC version unaware middleboxes,
	but not against on-path attackers.	but not against on-path attackers.

	All ciphersuites currently defined for TLS 1.3 - and therefore QUIC -	All ciphersuites currently defined for TLS 1.3 - and therefore QUIC -
	have a 16-byte authentication tag and produce an output 16 bytes	have a 16-byte authentication tag and produce an output 16 bytes

	skipping to change at page 21, line 15 ¶	skipping to change at page 21, line 25 ¶
	Some AEAD functions have limits for how many packets can be encrypted	Some AEAD functions have limits for how many packets can be encrypted
	under the same key and IV (see for example [AEBounds]). This might	under the same key and IV (see for example [AEBounds]). This might
	be lower than the packet number limit. An endpoint MUST initiate a	be lower than the packet number limit. An endpoint MUST initiate a
	key update (Section 6.2) prior to exceeding any limit set for the	key update (Section 6.2) prior to exceeding any limit set for the
	AEAD that is in use.	AEAD that is in use.

	TLS maintains a separate sequence number that is used for record	TLS maintains a separate sequence number that is used for record
	protection on the connection that is hosted on stream 0. This	protection on the connection that is hosted on stream 0. This
	sequence number is not visible to QUIC.	sequence number is not visible to QUIC.


	5.6. Receiving Protected Packets	5.6. Packet Number Protection

		QUIC packets are protected using a key that is derived from the
		current set of secrets. The key derived using the "pn" label is used
		to protect the packet number from casual observation. The packet
		number protection algorithm depends on the negotiated AEAD.

		Packet number protection is applied after packet protection is
		applied (see Section 5.4). The ciphertext of the packet is sampled
		and used as input to an encryption algorithm.

		In sampling the packet ciphertext, the packet number length is
		assumed to be the smaller of the maximum possible packet number
		encoding (4 octets), or the size of the protected packet minus the
		minimum expansion for the AEAD. For example, the sampled ciphertext
		for a packet with a short header can be determined by:

		"sample_offset = min(1 + connection_id_length + 4, packet_length -
		aead_expansion) sample =
		packet[sample_offset..sample_offset+sample_length] "

		To ensure that this process does not sample the packet number, packet
		number protection algorithms MUST NOT sample more ciphertext than the
		minimum expansion of the corresponding AEAD.

		Packet number protection is applied to the packet number encoded as
		described in Section 4.8 of [QUIC-TRANSPORT]. Since the length of
		the packet number is stored in the first octet of the encoded packet
		number, it may be necessary to progressively decrypt the packet
		number.

		Before a TLS ciphersuite can be used with QUIC, a packet protection
		algorithm MUST be specifed for the AEAD used with that ciphersuite.
		This document defines algorithms for AEAD_AES_128_GCM,
		AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs
		are defined in [RFC5116]), and AEAD_CHACHA20_POLY1305 ([CHACHA]).

		5.6.1. AES-Based Packet Number Protection

		This section defines the packet protection algorithm for
		AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and
		AEAD_AES_256_CCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit
		AES [AES] in counter (CTR) mode. AEAD_AES_256_GCM, and
		AEAD_AES_256_CCM use 256-bit AES in CTR mode.

		This algorithm samples 16 octets from the packet ciphertext. This
		value is used as the counter input to AES-CTR.

		encrypted_pn = AES-CTR(pn_key, sample, packet_number)

		5.6.2. ChaCha20-Based Packet Number Protection

		When AEAD_CHACHA20_POLY1305 is in use, packet number protection uses
		the raw ChaCha20 function as defined in Section 2.4 of [CHACHA].
		This uses a 256-bit key and 16 octets sampled from the packet
		protection output.

		The first 4 octets of the sampled ciphertext are interpreted as a
		32-bit number in little-endian order and are used as the block count.
		The remaining 12 octets are interpreted as three concatenated 32-bit
		numbers in little-endian order and used as the nonce.

		The encoded packet number is then encrypted with ChaCha20 directly.
		In pseudocode:

		counter = DecodeLE(sample[0..3])
		nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15])
		encrypted_pn = ChaCha20(pn_key, counter, nonce, packet_number)

		5.7. Receiving Protected Packets

	Once an endpoint successfully receives a packet with a given packet	Once an endpoint successfully receives a packet with a given packet
	number, it MUST discard all packets with higher packet numbers if	number, it MUST discard all packets with higher packet numbers if
	they cannot be successfully unprotected with either the same key, or	they cannot be successfully unprotected with either the same key, or
	- if there is a key update - the next packet protection key (see	- if there is a key update - the next packet protection key (see
	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.7. Packet Number Gaps

	Section 6.8.5.1 of [QUIC-TRANSPORT] also requires a secret to compute
	packet number gaps on connection ID transitions. That secret is
	computed as:

	packet_number_secret =
	TLS-Exporter("EXPORTER-QUIC packet number", "", 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
	packets, the KEY_PHASE bit in the public flags is toggled. 0-RTT	packets, the KEY_PHASE bit in the public flags is toggled. 0-RTT

	skipping to change at page 35, line 13 ¶	skipping to change at page 36, line 21 ¶
	during the handshake, but an excessive number might be used to	during the handshake, but an excessive number might be used to
	generate unnecessary work. Once the TLS handshake is complete,	generate unnecessary work. Once the TLS handshake is complete,
	endpoints MUST NOT send TLS application data records. Receiving TLS	endpoints MUST NOT send TLS application data records. Receiving TLS
	application data MUST be treated as a connection error of type	application data MUST be treated as a connection error of type
	PROTOCOL_VIOLATION.	PROTOCOL_VIOLATION.

	While there are legitimate uses for some redundant packets,	While there are legitimate uses for some redundant packets,
	implementations SHOULD track redundant packets and treat excessive	implementations SHOULD track redundant packets and treat excessive
	volumes of any non-productive packets as indicative of an attack.	volumes of any non-productive packets as indicative of an attack.


		10.3. Packet Number Protection Analysis

		Packet number protection relies the packet protection AEAD being a
		pseudorandom function (PRF), which is not a property that AEAD
		algorithms guarantee. Therefore, no strong assurances about the
		general security of this mechanism can be shown in the general case.
		The AEAD algorithms described in this document are assumed to be
		PRFs.

		The packet number protection algorithms defined in this document take
		the form:

		"encrypted_pn = packet_number XOR PRF(pn_key, sample) "

		This construction is secure against chosen plaintext attacks (IND-
		CPA) [IMC].

		Use of the same key and ciphertext sample more than once risks
		compromising packet number protection. Protecting two different
		packet numbers with the same key and ciphertext sample reveals the
		exclusive OR of those packet numbers. Assuming that the AEAD acts as
		a PRF, if L bits are sampled, the odds of two ciphertext samples
		being identical approach 2^(-L/2), that is, the birthday bound. For
		the algorithms described in this document, that probability is one in
		2^64.

		Note: In some cases, inputs shorter than the full size required by
		the packet protection algorithm might be used.

		To prevent an attacker from modifying packet numbers, values of
		packet numbers are transitively authenticated using packet
		protection; packet numbers are part of the authenticated additional
		data. A falsified or modified packet number can only be detected
		once the packet protection is removed.

		An attacker can guess values for packet numbers and have an endpoint
		confirm guesses through timing side channels. If the recipient of a
		packet discards packets with duplicate packet numbers without
		attempting to remove packet protection they could reveal through
		timing side-channels that the packet number matches a received
		packet. For authentication to be free from side-channels, the entire
		process of packet number protection removal, packet number recovery,
		and packet protection removal MUST be applied together without timing
		and other side-channels.

		For the sending of packets, construction and protection of packet
		payloads and packet numbers MUST be free from side-channels that
		would reveal the packet number or its encoded size.

	11. Error Codes	11. Error Codes

	This section defines error codes from the error code space used in	This section defines error codes from the error code space used in
	[QUIC-TRANSPORT].	[QUIC-TRANSPORT].

	The following error codes are defined when TLS is used for the crypto	The following error codes are defined when TLS is used for the crypto
	handshake:	handshake:

	TLS_HANDSHAKE_FAILED (0x201): The TLS handshake failed.	TLS_HANDSHAKE_FAILED (0x201): The TLS handshake failed.


	skipping to change at page 36, line 28 ¶	skipping to change at page 38, line 34 ¶
	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	[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
	<https://www.rfc-editor.org/info/rfc5116>.	<https://www.rfc-editor.org/info/rfc5116>.


	[FIPS180] Department of Commerce, National., "NIST FIPS 180-4,	[AES] "Advanced encryption standard (AES)", National Institute
	Secure Hash Standard", March 2012,	of Standards and Technology report,
	<http://csrc.nist.gov/publications/fips/fips180-4/	DOI 10.6028/nist.fips.197, November 2001.
	fips-180-4.pdf>.
		[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
		Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
		<https://www.rfc-editor.org/info/rfc7539>.

	[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand	[HKDF] 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>.

	[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-11 (work in progress), April 2018.	transport-12 (work in progress), May 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>.


		[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>.

	[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	[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>.


		[SHA] Dang, Q., "Secure Hash Standard", National Institute of
		Standards and Technology report,
		DOI 10.6028/nist.fips.180-4, July 2015.

	[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-04 (work	and DTLS", draft-ietf-tls-iana-registry-updates-04 (work
	in progress), February 2018.	in progress), February 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-21 (work in progress),	Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
	July 2017.	July 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>.


		[IMC] Katz, J. and Y. Lindell, "Introduction to Modern
		Cryptography, Second Edition", ISBN 978-1466570269,
		November 2014.

	[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-11 (work in progress), April	QUIC", draft-ietf-quic-http-12 (work in progress), May
	2018.	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-11 (work	and Congestion Control", draft-ietf-quic-recovery-11 (work

	in progress), April 2018.	in progress), May 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>.

End of changes. 21 change blocks.
	77 lines changed or deleted	214 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/