draft-ietf-quic-tls-30.txt		draft-ietf-quic-tls-31.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: March 14, 2021 sn3rd		Expires: 29 March 2021 sn3rd
	September 10, 2020		25 September 2020
	Using TLS to Secure QUIC		Using TLS to Secure QUIC
	draft-ietf-quic-tls-30		draft-ietf-quic-tls-31
	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 March 14, 2021.		This Internet-Draft will expire on 29 March 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
	2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5		2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5
	3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
	4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8		4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8
	4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 10		4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9
	4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10		4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10
	4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 11		4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10
	4.1.3. Sending and Receiving Handshake Messages . . . . . . 11		4.1.3. Sending and Receiving Handshake Messages . . . . . . 10
	4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 13		4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12
	4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 14		4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 14
	4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 15		4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 15
	4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 16		4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15
	4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 17		4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 16
	4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 17		4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 17
	4.6. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 18		4.6. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.6.1. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . 19		4.6.1. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . 18
	4.6.2. Accepting and Rejecting 0-RTT . . . . . . . . . . . . 19		4.6.2. Accepting and Rejecting 0-RTT . . . . . . . . . . . . 18
	4.6.3. Validating 0-RTT Configuration . . . . . . . . . . . 20		4.6.3. Validating 0-RTT Configuration . . . . . . . . . . . 19
	4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 20		4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 19
	4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 20		4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 19
	4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 21		4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 20
	4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 21		4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 20
	4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 22		4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 21
	4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 22		4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 21
	5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 22		5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 21
	5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 23		5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 22
	5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 24		5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 23
	5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 25		5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 24
	5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 26		5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 25
	5.4.1. Header Protection Application . . . . . . . . . . . . 26		5.4.1. Header Protection Application . . . . . . . . . . . . 25
	5.4.2. Header Protection Sample . . . . . . . . . . . . . . 28		5.4.2. Header Protection Sample . . . . . . . . . . . . . . 27
	5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 30		5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 29
	5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 30		5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 29
	5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 30		5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 29
	5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 31		5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30
	5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 31		5.7. Receiving Out-of-Order Protected Packets . . . . . . . . 30
	5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 33		5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 32
	6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 34		6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 33
	6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 35		6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 34
	6.2. Responding to a Key Update . . . . . . . . . . . . . . . 36		6.2. Responding to a Key Update . . . . . . . . . . . . . . . 35
	6.3. Timing of Receive Key Generation . . . . . . . . . . . . 37		6.3. Timing of Receive Key Generation . . . . . . . . . . . . 36
	6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 38		6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 37
	6.5. Receiving with Different Keys . . . . . . . . . . . . . . 38		6.5. Receiving with Different Keys . . . . . . . . . . . . . . 37
	6.6. Limits on AEAD Usage . . . . . . . . . . . . . . . . . . 39		6.6. Limits on AEAD Usage . . . . . . . . . . . . . . . . . . 38
	6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 41		6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 40
	7. Security of Initial Messages . . . . . . . . . . . . . . . . 41		7. Security of Initial Messages . . . . . . . . . . . . . . . . 40
	8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 41		8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 40
	8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 42		8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 41
	8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 42		8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 41
	8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 43		8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 42
	8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 43		8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 42
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 43		9. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 44		9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 43
	9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 44		9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 43
	9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 45		9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 44
	9.4. Header Protection Analysis . . . . . . . . . . . . . . . 45		9.4. Header Protection Analysis . . . . . . . . . . . . . . . 44
	9.5. Header Protection Timing Side-Channels . . . . . . . . . 46		9.5. Header Protection Timing Side-Channels . . . . . . . . . 45
	9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 47		9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 46
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 47		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
	11.1. Normative References . . . . . . . . . . . . . . . . . . 47		11.1. Normative References . . . . . . . . . . . . . . . . . . 46
	11.2. Informative References . . . . . . . . . . . . . . . . . 49		11.2. Informative References . . . . . . . . . . . . . . . . . 48
	Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 50		Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 49
	A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 50		A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 51		A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 50
	A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 53		A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 52
	A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 54		A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 53
	A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 54		A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 53
	Appendix B. AEAD Algorithm Analysis . . . . . . . . . . . . . . 56		Appendix B. AEAD Algorithm Analysis . . . . . . . . . . . . . . 55
	B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage		B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage
	Limits . . . . . . . . . . . . . . . . . . . . . . . . . 56		Limits . . . . . . . . . . . . . . . . . . . . . . . . . 55
	B.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 57		B.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 56
	B.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 57		B.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 56
	B.2. Analysis of AEAD_AES_128_CCM Usage Limits . . . . . . . . 58		B.2. Analysis of AEAD_AES_128_CCM Usage Limits . . . . . . . . 57
	B.2.1. Confidentiality Limits . . . . . . . . . . . . . . . 58		B.2.1. Confidentiality Limits . . . . . . . . . . . . . . . 57
	B.2.2. Integrity Limits . . . . . . . . . . . . . . . . . . 58		B.2.2. Integrity Limits . . . . . . . . . . . . . . . . . . 57
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 59		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 58
	C.1. Since draft-ietf-quic-tls-29 . . . . . . . . . . . . . . 59		C.1. Since draft-ietf-quic-tls-30 . . . . . . . . . . . . . . 58
	C.2. Since draft-ietf-quic-tls-28 . . . . . . . . . . . . . . 59		C.2. Since draft-ietf-quic-tls-29 . . . . . . . . . . . . . . 58
	C.3. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 59		C.3. Since draft-ietf-quic-tls-28 . . . . . . . . . . . . . . 58
	C.4. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 59		C.4. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 58
	C.5. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 59		C.5. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 58
	C.6. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 59		C.6. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 59
	C.7. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 60		C.7. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 59
	C.8. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 60		C.8. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 59
	C.9. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 60		C.9. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 59
	C.10. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 60		C.10. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 59
	C.11. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 60		C.11. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 59
	C.12. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 60		C.12. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 59
	C.13. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 61		C.13. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 60
	C.14. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 61		C.14. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 60
	C.15. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 61		C.15. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 60
	C.16. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 61		C.16. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 60
	C.17. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 62		C.17. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 61
	C.18. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 62		C.18. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 61
	C.19. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 62		C.19. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 61
	C.20. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 62		C.20. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 61
	C.21. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 62		C.21. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 61
	C.22. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 62		C.22. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 61
	C.23. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 62		C.23. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 61
	C.24. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 62		C.24. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 61
	C.25. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 62		C.25. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 61
	C.26. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 63		C.26. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 62
	C.27. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 63		C.27. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 62
			C.28. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 62
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 63		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 63
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
	1. Introduction		1. Introduction
	This document describes how QUIC [QUIC-TRANSPORT] is secured using		This document describes how QUIC [QUIC-TRANSPORT] is secured using
	TLS [TLS13].		TLS [TLS13].
	TLS 1.3 provides critical latency improvements for connection		TLS 1.3 provides critical latency improvements for connection
	establishment over previous versions. Absent packet loss, most new		establishment over previous versions. Absent packet loss, most new
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	responsibility to deliver it reliably. Each chunk of data that is		responsibility to deliver it reliably. Each chunk of data that is
	produced by TLS is associated with the set of keys that TLS is		produced by TLS is associated with the set of keys that TLS is
	currently using. If QUIC needs to retransmit that data, it MUST use		currently using. If QUIC needs to retransmit that data, it MUST use
	the same keys even if TLS has already updated to newer keys.		the same keys even if TLS has already updated to newer keys.
	One important difference between TLS records (used with TCP) and QUIC		One important difference between TLS records (used with TCP) and QUIC
	CRYPTO frames is that in QUIC multiple frames may appear in the same		CRYPTO frames is that in QUIC multiple frames may appear in the same
	QUIC packet as long as they are associated with the same packet		QUIC packet as long as they are associated with the same packet
	number space. For instance, an endpoint can bundle a Handshake		number space. For instance, an endpoint can bundle a Handshake
	message and an ACK for some Handshake data into the same packet.		message and an ACK for some Handshake data into the same packet.
			Some frames are prohibited in different packet number spaces; see
	Some frames are prohibited in different packet number spaces. The		Section 12.5 of [QUIC-TRANSPORT].
	rules here generalize those of TLS, in that frames associated with
	establishing the connection can usually appear in packets in any
	packet number space, whereas those associated with transferring data
	can only appear in the application data packet number space:
	* PADDING, PING, and CRYPTO frames MAY appear in any packet number
	space.
	* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
	0x1c) MAY appear in any packet number space. CONNECTION_CLOSE
	frames signaling application errors (type 0x1d) MUST only appear
	in the application data packet number space.
	* ACK frames MAY appear in any packet number space, but can only
	acknowledge packets that appeared in that packet number space.
	However, as noted below, 0-RTT packets cannot contain ACK frames.
	* All other frame types MUST only be sent in the application data
	packet number space.
	Note that it is not possible to send the following frames in 0-RTT
	packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
	PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
	of these frames in 0-RTT packets as a connection error of type
	PROTOCOL_VIOLATION.
	Because packets could be reordered on the wire, QUIC uses the packet		Because packets could be reordered on the wire, QUIC uses the packet
	type to indicate which keys were used to protect a given packet, as		type to indicate which keys were used to protect a given packet, as
	shown in Table 1. When packets of different types need to be sent,		shown in Table 1. When packets of different types need to be sent,
	endpoints SHOULD use coalesced packets to send them in the same UDP		endpoints SHOULD use coalesced packets to send them in the same UDP
	datagram.		datagram.
	+=====================+=================+==================+		+=====================+=================+==================+
	| Packet Type | Encryption Keys | PN Space |		| Packet Type | Encryption Keys | PN Space |
	+=====================+=================+==================+		+=====================+=================+==================+
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 7 ¶
	available, then it is delivered to TLS in order.		available, then it is delivered to TLS in order.
	* If the packet is from a previously installed encryption level, it		* If the packet is from a previously installed encryption level, it
	MUST NOT contain data that extends past the end of previously		MUST NOT contain data that extends past the end of previously
	received data in that flow. Implementations MUST treat any		received data in that flow. Implementations MUST treat any
	violations of this requirement as a connection error of type		violations of this requirement as a connection error of type
	PROTOCOL_VIOLATION.		PROTOCOL_VIOLATION.
	* If the packet is from a new encryption level, it is saved for		* If the packet is from a new encryption level, it is saved for
	later processing by TLS. Once TLS moves to receiving from this		later processing by TLS. Once TLS moves to receiving from this
	encryption level, saved data can be provided to TLS. When		encryption level, saved data can be provided to TLS. When TLS
	providing data from any new encryption level to TLS, if there is		provides keys for a higher encryption level, if there is data from
	data from a previous encryption level that TLS has not consumed,		a previous encryption level that TLS has not consumed, this MUST
	this MUST be treated as a connection error of type		be treated as a connection error of type PROTOCOL_VIOLATION.
	PROTOCOL_VIOLATION.
	Each time that TLS is provided with new data, new handshake bytes are		Each time that TLS is provided with new data, new handshake bytes are
	requested from TLS. TLS might not provide any bytes if the handshake		requested from TLS. TLS might not provide any bytes if the handshake
	messages it has received are incomplete or it has no data to send.		messages it has received are incomplete or it has no data to send.
	The content of CRYPTO frames might either be processed incrementally		The content of CRYPTO frames might either be processed incrementally
	by TLS or buffered until complete messages or flights are available.		by TLS or buffered until complete messages or flights are available.
	TLS is responsible for buffering handshake bytes that have arrived in		TLS is responsible for buffering handshake bytes that have arrived in
	order. QUIC is responsible for buffering handshake bytes that arrive		order. QUIC is responsible for buffering handshake bytes that arrive
	out of order or for encryption levels that are not yet ready. QUIC		out of order or for encryption levels that are not yet ready. QUIC
	skipping to change at page 16, line 33 ¶		skipping to change at page 15, line 45 ¶
	whether to accept the new incoming QUIC connection. If the		whether to accept the new incoming QUIC connection. If the
	ClientHello spans multiple Initial packets, such servers would need		ClientHello spans multiple Initial packets, such servers would need
	to buffer the first received fragments, which could consume excessive		to buffer the first received fragments, which could consume excessive
	resources if the client's address has not yet been validated. To		resources if the client's address has not yet been validated. To
	avoid this, servers MAY use the Retry feature (see Section 8.1 of		avoid this, servers MAY use the Retry feature (see Section 8.1 of
	[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from		[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from
	clients with a validated address.		clients with a validated address.
	QUIC packet and framing add at least 36 bytes of overhead to the		QUIC packet and framing add at least 36 bytes of overhead to the
	ClientHello message. That overhead increases if the client chooses a		ClientHello message. That overhead increases if the client chooses a
	connection ID without zero length. Overheads also do not include the		source connection ID longer than zero bytes. Overheads also do not
	token or a connection ID longer than 8 bytes, both of which might be		include the token or a destination connection ID longer than 8 bytes,
	required if a server sends a Retry packet.		both of which might be required if a server sends a Retry packet.
	A typical TLS ClientHello can easily fit into a 1200-byte packet.		A typical TLS ClientHello can easily fit into a 1200-byte packet.
	However, in addition to the overheads added by QUIC, there are		However, in addition to the overheads added by QUIC, there are
	several variables that could cause this limit to be exceeded. Large		several variables that could cause this limit to be exceeded. Large
	session tickets, multiple or large key shares, and long lists of		session tickets, multiple or large key shares, and long lists of
	supported ciphers, signature algorithms, versions, QUIC transport		supported ciphers, signature algorithms, versions, QUIC transport
	parameters, and other negotiable parameters and extensions could		parameters, and other negotiable parameters and extensions could
	cause this message to grow.		cause this message to grow.
	For servers, in addition to connection IDs and tokens, the size of		For servers, in addition to connection IDs and tokens, the size of
	skipping to change at page 18, line 21 ¶		skipping to change at page 17, line 28 ¶
	protocols could depend on state that is retained between resumed		protocols could depend on state that is retained between resumed
	connections.		connections.
	Clients can store any state required for resumption along with the		Clients can store any state required for resumption along with the
	session ticket. Servers can use the session ticket to help carry		session ticket. Servers can use the session ticket to help carry
	state.		state.
	Session resumption allows servers to link activity on the original		Session resumption allows servers to link activity on the original
	connection with the resumed connection, which might be a privacy		connection with the resumed connection, which might be a privacy
	issue for clients. Clients can choose not to enable resumption to		issue for clients. Clients can choose not to enable resumption to
	avoid creating this correlation. Client SHOULD NOT reuse tickets as		avoid creating this correlation. Clients SHOULD NOT reuse tickets as
	that allows entities other than the server to correlate connections;		that allows entities other than the server to correlate connections;
	see Section C.4 of [TLS13].		see Section C.4 of [TLS13].
	4.6. 0-RTT		4.6. 0-RTT
	The 0-RTT feature in QUIC allows a client to send application data		The 0-RTT feature in QUIC allows a client to send application data
	before the handshake is complete. This is made possible by reusing		before the handshake is complete. This is made possible by reusing
	negotiated parameters from a previous connection. To enable this,		negotiated parameters from a previous connection. To enable this,
	0-RTT depends on the client remembering critical parameters and		0-RTT depends on the client remembering critical parameters and
	providing the server with a TLS session ticket that allows the server		providing the server with a TLS session ticket that allows the server
	skipping to change at page 21, line 45 ¶		skipping to change at page 20, line 48 ¶
	Though an endpoint might retain older keys, new data MUST be sent at		Though an endpoint might retain older keys, new data MUST be sent at
	the highest currently-available encryption level. Only ACK frames		the highest currently-available encryption level. Only ACK frames
	and retransmissions of data in CRYPTO frames are sent at a previous		and retransmissions of data in CRYPTO frames are sent at a previous
	encryption level. These packets MAY also include PADDING frames.		encryption level. These packets MAY also include PADDING frames.
	4.9.1. Discarding Initial Keys		4.9.1. Discarding Initial Keys
	Packets protected with Initial secrets (Section 5.2) are not		Packets protected with Initial secrets (Section 5.2) are not
	authenticated, meaning that an attacker could spoof packets with the		authenticated, meaning that an attacker could spoof packets with the
	intent to disrupt a connection. To limit these attacks, Initial		intent to disrupt a connection. To limit these attacks, Initial
	packet protection keys can be discarded more aggressively than other		packet protection keys are discarded more aggressively than other
	keys.		keys.
	The successful use of Handshake packets indicates that no more		The successful use of Handshake packets indicates that no more
	Initial packets need to be exchanged, as these keys can only be		Initial packets need to be exchanged, as these keys can only be
	produced after receiving all CRYPTO frames from Initial packets.		produced after receiving all CRYPTO frames from Initial packets.
	Thus, a client MUST discard Initial keys when it first sends a		Thus, a client MUST discard Initial keys when it first sends a
	Handshake packet and a server MUST discard Initial keys when it first		Handshake packet and a server MUST discard Initial keys when it first
	successfully processes a Handshake packet. Endpoints MUST NOT send		successfully processes a Handshake packet. Endpoints MUST NOT send
	Initial packets after this point.		Initial packets after this point.
	skipping to change at page 31, line 42 ¶		skipping to change at page 30, line 42 ¶
	Once a client has installed 1-RTT keys, it MUST NOT send any more		Once a client has installed 1-RTT keys, it MUST NOT send any more
	0-RTT packets.		0-RTT packets.
	Note: 0-RTT data can be acknowledged by the server as it receives		Note: 0-RTT data can be acknowledged by the server as it receives
	it, but any packets containing acknowledgments of 0-RTT data		it, but any packets containing acknowledgments of 0-RTT data
	cannot have packet protection removed by the client until the TLS		cannot have packet protection removed by the client until the TLS
	handshake is complete. The 1-RTT keys necessary to remove packet		handshake is complete. The 1-RTT keys necessary to remove packet
	protection cannot be derived until the client receives all server		protection cannot be derived until the client receives all server
	handshake messages.		handshake messages.
	5.7. Receiving Out-of-Order Protected Frames		5.7. Receiving Out-of-Order Protected Packets
	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. Endpoints in either role MUST NOT decrypt 1-RTT packets from		client. Endpoints in either role MUST NOT decrypt 1-RTT packets from
	their peer prior to completing the handshake.		their peer prior to completing the handshake.
	Even though 1-RTT keys are available to a server after receiving the		Even though 1-RTT keys are available to a server after receiving the
	first handshake messages from a client, it is missing assurances on		first handshake messages from a client, it is missing assurances on
	the client state:		the client state:
	* The client is not authenticated, unless the server has chosen to		* The client is not authenticated, unless the server has chosen to
	use a pre-shared key and validated the client's pre-shared key		use a pre-shared key and validated the client's pre-shared key
	binder; see Section 4.2.11 of [TLS13].		binder; see Section 4.2.11 of [TLS13].
	* The client has not demonstrated liveness, unless a RETRY packet		* The client has not demonstrated liveness, unless the server has
	was used.		validated the client's address with a Retry packet or other means;
			see Section 8.1 of [QUIC-TRANSPORT].
	* Any received 0-RTT data that the server responds to might be due		* Any received 0-RTT data that the server responds to might be due
	to a replay attack.		to a replay attack.
	Therefore, the server's use of 1-RTT keys before the handshake is		Therefore, the server's use of 1-RTT keys before the handshake is
	complete is limited to sending data. A server MUST NOT process		complete is limited to sending data. A server MUST NOT process
	incoming 1-RTT protected packets before the TLS handshake is		incoming 1-RTT protected packets before the TLS handshake is
	complete. Because sending acknowledgments indicates that all frames		complete. Because sending acknowledgments indicates that all frames
	in a packet have been processed, a server cannot send acknowledgments		in a packet have been processed, a server cannot send acknowledgments
	for 1-RTT packets until the TLS handshake is complete. Received		for 1-RTT packets until the TLS handshake is complete. Received
	skipping to change at page 33, line 42 ¶		skipping to change at page 32, line 42 ¶
	ODCID Length (8),		ODCID Length (8),
	Original Destination Connection ID (0..160),		Original Destination Connection ID (0..160),
	Header Form (1) = 1,		Header Form (1) = 1,
	Fixed Bit (1) = 1,		Fixed Bit (1) = 1,
	Long Packet Type (2) = 3,		Long Packet Type (2) = 3,
	Type-Specific Bits (4),		Type-Specific Bits (4),
	Version (32),		Version (32),
	DCID Len (8),		DCID Len (8),
	Destination Connection ID (0..160),		Destination Connection ID (0..160),
	SCID Len (8),		SCID Len (8),
			Source Connection ID (0..160),
	Retry Token (..),		Retry Token (..),
	}		}
	Figure 8: Retry Pseudo-Packet		Figure 8: Retry Pseudo-Packet
	The Retry Pseudo-Packet is not sent over the wire. It is computed by		The Retry Pseudo-Packet is not sent over the wire. It is computed by
	taking the transmitted Retry packet, removing the Retry Integrity Tag		taking the transmitted Retry packet, removing the Retry Integrity Tag
	and prepending the two following fields:		and prepending the two following fields:
	ODCID Length: The ODCID Length field contains the length in bytes of		ODCID Length: The ODCID Length field contains the length in bytes of
	skipping to change at page 47, line 38 ¶		skipping to change at page 46, line 38 ¶
	header protection keys. This version of QUIC uses the string "quic".		header protection keys. This version of QUIC uses the string "quic".
	Other versions can use a version-specific label in place of that		Other versions can use a version-specific label in place of that
	string.		string.
	The initial secrets use a key that is specific to the negotiated QUIC		The initial secrets use a key that is specific to the negotiated QUIC
	version. New QUIC versions SHOULD define a new salt value used in		version. New QUIC versions SHOULD define a new salt value used in
	calculating initial secrets.		calculating initial secrets.
	10. IANA Considerations		10. IANA Considerations
	This document does not create any new IANA registries, but it		This document registers the quic_transport_parameters extension found
	registers the values in the following registries:		in Section 8.2 in the TLS ExtensionType Values Registry
			[TLS-REGISTRIES].
	* TLS ExtensionType Values Registry [TLS-REGISTRIES] - IANA is to
	register the quic_transport_parameters extension found in
	Section 8.2. The Recommended column is to be marked Yes. The TLS
	1.3 Column is to include CH and EE.
	* QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to		The Recommended column is to be marked Yes. The TLS 1.3 Column is to
	register the KEY_UPDATE_ERROR (0xe), as described in Section 6.7.		include CH and EE.
	11. References		11. References
	11.1. Normative References		11.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>.
	[AES] "Advanced encryption standard (AES)",		[AES] "Advanced encryption standard (AES)", National Institute
	DOI 10.6028/nist.fips.197, National Institute of Standards		of Standards and Technology report,
	and Technology report, November 2001,		DOI 10.6028/nist.fips.197, November 2001,
	<https://doi.org/10.6028/nist.fips.197>.		<https://doi.org/10.6028/nist.fips.197>.
	[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,		Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
	<https://www.rfc-editor.org/info/rfc8439>.		<https://www.rfc-editor.org/info/rfc8439>.
	[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-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", Work in Progress, Internet-Draft,		and Congestion Control", Work in Progress, Internet-Draft,
	draft-ietf-quic-recovery-30, September 10, 2020,		draft-ietf-quic-recovery-31, 25 September 2020,
	<https://tools.ietf.org/html/draft-ietf-quic-recovery-30>.		<https://tools.ietf.org/html/draft-ietf-quic-recovery-31>.
	[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", Work in Progress,		Multiplexed and Secure Transport", Work in Progress,
	Internet-Draft, draft-ietf-quic-transport-30, September		Internet-Draft, draft-ietf-quic-transport-31, 25 September
	10, 2020, <https://tools.ietf.org/html/draft-ietf-quic-		2020, <https://tools.ietf.org/html/draft-ietf-quic-
	transport-30>.		transport-31>.
	[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>.
	[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",		[SHA] Dang, Q., "Secure Hash Standard", National Institute of
	DOI 10.6028/nist.fips.180-4, National Institute of		Standards and Technology report,
	Standards and Technology report, July 2015,		DOI 10.6028/nist.fips.180-4, July 2015,
	<https://doi.org/10.6028/nist.fips.180-4>.		<https://doi.org/10.6028/nist.fips.180-4>.
	[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", RFC 8447, DOI 10.17487/RFC8447, August 2018,		and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
	<https://www.rfc-editor.org/info/rfc8447>.		<https://www.rfc-editor.org/info/rfc8447>.
	[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	11.2. Informative References		11.2. Informative References
	[AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated		[AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated
	Encryption Use in TLS", March 8, 2016,		Encryption Use in TLS", 8 March 2016,
	<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.		<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
	[CCM-ANALYSIS]		[CCM-ANALYSIS]
	Jonsson, J., "On the Security of CTR + CBC-MAC",		Jonsson, J., "On the Security of CTR + CBC-MAC", Selected
	DOI 10.1007/3-540-36492-7_7, Selected Areas in		Areas in Cryptography pp. 76-93,
	Cryptography pp. 76-93, 2003,		DOI 10.1007/3-540-36492-7_7, 2003,
	<https://doi.org/10.1007/3-540-36492-7_7>.		<https://doi.org/10.1007/3-540-36492-7_7>.
	[COMPRESS] Ghedini, A. and V. Vasiliev, "TLS Certificate		[COMPRESS] Ghedini, A. and V. Vasiliev, "TLS Certificate
	Compression", Work in Progress, Internet-Draft, draft-		Compression", Work in Progress, Internet-Draft, draft-
	ietf-tls-certificate-compression-10, January 6, 2020,		ietf-tls-certificate-compression-10, 6 January 2020,
	<http://www.ietf.org/internet-drafts/draft-ietf-tls-		<http://www.ietf.org/internet-drafts/draft-ietf-tls-
	certificate-compression-10.txt>.		certificate-compression-10.txt>.
	[GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, "The Multi-		[GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, "The Multi-
	user Security of GCM, Revisited",		user Security of GCM, Revisited", Proceedings of the 2018
	DOI 10.1145/3243734.3243816, Proceedings of the 2018 ACM		ACM SIGSAC Conference on Computer and
	SIGSAC Conference on Computer and Communications Security,		Communications Security, DOI 10.1145/3243734.3243816,
	January 2018, <https://doi.org/10.1145/3243734.3243816>.		January 2018, <https://doi.org/10.1145/3243734.3243816>.
	[HTTP2-TLS13]		[HTTP2-TLS13]
	Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,		Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
	DOI 10.17487/RFC8740, February 2020,		DOI 10.17487/RFC8740, February 2020,
	<https://www.rfc-editor.org/info/rfc8740>.		<https://www.rfc-editor.org/info/rfc8740>.
	[IMC] Katz, J. and Y. Lindell, "Introduction to Modern		[IMC] Katz, J. and Y. Lindell, "Introduction to Modern
	Cryptography, Second Edition", ISBN 978-1466570269,		Cryptography, Second Edition", ISBN 978-1466570269, 6
	November 6, 2014.		November 2014.
	[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:		[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
	AEAD Revisited", DOI 10.1007/978-3-030-26948-7_9, Advances		AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
	in Cryptology - CRYPTO 2019 pp. 235-265, 2019,		235-265, DOI 10.1007/978-3-030-26948-7_9, 2019,
	<https://doi.org/10.1007/978-3-030-26948-7_9>.		<https://doi.org/10.1007/978-3-030-26948-7_9>.
	[QUIC-HTTP]		[QUIC-HTTP]
	Bishop, M., Ed., "Hypertext Transfer Protocol Version 3		Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
	quic-http-30, September 10, 2020,		quic-http-31, 25 September 2020,
	<https://tools.ietf.org/html/draft-ietf-quic-http-30>.		<https://tools.ietf.org/html/draft-ietf-quic-http-31>.
	[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>.
	[ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust		[ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust
	Channels: Handling Unreliable Networks in the Record		Channels: Handling Unreliable Networks in the Record
	Layers of QUIC and DTLS 1.3", May 16, 2020,		Layers of QUIC and DTLS 1.3", 16 May 2020,
	<https://eprint.iacr.org/2020/718>.		<https://eprint.iacr.org/2020/718>.
	Appendix A. Sample Packet Protection		Appendix A. Sample Packet Protection
	This section shows examples of packet protection so that		This section shows examples of packet protection so that
	implementations can be verified incrementally. Samples of Initial		implementations can be verified incrementally. Samples of Initial
	packets from both client and server, plus a Retry packet are defined.		packets from both client and server, plus a Retry packet are defined.
	These packets use an 8-byte client-chosen Destination Connection ID		These packets use an 8-byte client-chosen Destination Connection ID
	of 0x8394c8f03e515708. Some intermediate values are included. All		of 0x8394c8f03e515708. Some intermediate values are included. All
	values are shown in hexadecimal.		values are shown in hexadecimal.
	skipping to change at page 53, line 5 ¶		skipping to change at page 52, line 5 ¶
	= 1e9cdb9909		= 1e9cdb9909
	header[0] ^= mask[0] & 0x0f		header[0] ^= mask[0] & 0x0f
	= cd		= cd
	header[18..21] ^= mask[1..4]		header[18..21] ^= mask[1..4]
	= 9cdb990b		= 9cdb990b
	header = cdff00001d088394c8f03e5157080000449e9cdb990b		header = cdff00001d088394c8f03e5157080000449e9cdb990b
	The resulting protected packet is:		The resulting protected packet is:
	cdff00001d088394c8f03e5157080000 449e9cdb990bfb66bc6a93032b50dd89		cdff00001f088394c8f03e5157080000 449e9cdb990bfb66bc6a93032b50dd89
	73972d149421874d3849e3708d71354e a33bcdc356f3ea6e2a1a1bd7c3d14003		73972d149421874d3849e3708d71354e a33bcdc356f3ea6e2a1a1bd7c3d14003
	8d3e784d04c30a2cdb40c32523aba2da fe1c1bf3d27a6be38fe38ae033fbb071		8d3e784d04c30a2cdb40c32523aba2da fe1c1bf3d27a6be38fe38ae033fbb071
	3c1c73661bb6639795b42b97f77068ea d51f11fbf9489af2501d09481e6c64d4		3c1c73661bb6639795b42b97f77068ea d51f11fbf9489af2501d09481e6c64d4
	b8551cd3cea70d830ce2aeeec789ef55 1a7fbe36b3f7e1549a9f8d8e153b3fac		b8551cd3cea70d830ce2aeeec789ef55 1a7fbe36b3f7e1549a9f8d8e153b3fac
	3fb7b7812c9ed7c20b4be190ebd89956 26e7f0fc887925ec6f0606c5d36aa81b		3fb7b7812c9ed7c20b4be190ebd89956 26e7f0fc887925ec6f0606c5d36aa81b
	ebb7aacdc4a31bb5f23d55faef5c5190 5783384f375a43235b5c742c78ab1bae		ebb7aacdc4a31bb5f23d55faef5c5190 5783384f375a43235b5c742c78ab1bae
	0a188b75efbde6b3774ed61282f9670a 9dea19e1566103ce675ab4e21081fb58		0a188b75efbde6b3774ed61282f9670a 9dea19e1566103ce675ab4e21081fb58
	60340a1e88e4f10e39eae25cd685b109 29636d4f02e7fad2a5a458249f5c0298		60340a1e88e4f10e39eae25cd685b109 29636d4f02e7fad2a5a458249f5c0298
	a6d53acbe41a7fc83fa7cc01973f7a74 d1237a51974e097636b6203997f921d0		a6d53acbe41a7fc83fa7cc01973f7a74 d1237a51974e097636b6203997f921d0
	7bc1940a6f2d0de9f5a11432946159ed 6cc21df65c4ddd1115f86427259a196c		7bc1940a6f2d0de9f5a11432946159ed 6cc21df65c4ddd1115f86427259a196c
	skipping to change at page 53, line 42 ¶		skipping to change at page 52, line 42 ¶
	1da2304d6a0fd5d07d08372202369661 59bef3cf904d722324dd852513df39ae		1da2304d6a0fd5d07d08372202369661 59bef3cf904d722324dd852513df39ae
	030d8173908da6364786d3c1bfcb19ea 77a63b25f1e7fc661def480c5d00d444		030d8173908da6364786d3c1bfcb19ea 77a63b25f1e7fc661def480c5d00d444
	56269ebd84efd8e3a8b2c257eec76060 682848cbf5194bc99e49ee75e4d0d254		56269ebd84efd8e3a8b2c257eec76060 682848cbf5194bc99e49ee75e4d0d254
	bad4bfd74970c30e44b65511d4ad0e6e c7398e08e01307eeeea14e46ccd87cf3		bad4bfd74970c30e44b65511d4ad0e6e c7398e08e01307eeeea14e46ccd87cf3
	6b285221254d8fc6a6765c524ded0085 dca5bd688ddf722e2c0faf9d0fb2ce7a		6b285221254d8fc6a6765c524ded0085 dca5bd688ddf722e2c0faf9d0fb2ce7a
	0c3f2cee19ca0ffba461ca8dc5d2c817 8b0762cf67135558494d2a96f1a139f0		0c3f2cee19ca0ffba461ca8dc5d2c817 8b0762cf67135558494d2a96f1a139f0
	edb42d2af89a9c9122b07acbc29e5e72 2df8615c343702491098478a389c9872		edb42d2af89a9c9122b07acbc29e5e72 2df8615c343702491098478a389c9872
	a10b0c9875125e257c7bfdf27eef4060 bd3d00f4c14fd3e3496c38d3c5d1a566		a10b0c9875125e257c7bfdf27eef4060 bd3d00f4c14fd3e3496c38d3c5d1a566
	8c39350effbc2d16ca17be4ce29f02ed 969504dda2a8c6b9ff919e693ee79e09		8c39350effbc2d16ca17be4ce29f02ed 969504dda2a8c6b9ff919e693ee79e09
	089316e7d1d89ec099db3b2b268725d8 88536a4b8bf9aee8fb43e82a4d919d48		089316e7d1d89ec099db3b2b268725d8 88536a4b8bf9aee8fb43e82a4d919d48
	1802771a449b30f3fa2289852607b660		395781bc0a3e8125b4dd506ca025eb37
	A.3. Server Initial		A.3. Server Initial
	The server sends the following payload in response, including an ACK		The server sends the following payload in response, including an ACK
	frame, a CRYPTO frame, and no PADDING frames:		frame, a CRYPTO frame, and no PADDING frames:
	02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739		02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
	88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94		88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
	0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00		0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
	020304		020304
	skipping to change at page 54, line 18 ¶		skipping to change at page 53, line 18 ¶
	As a result, after protection, the header protection sample is taken		As a result, after protection, the header protection sample is taken
	starting from the third protected octet:		starting from the third protected octet:
	sample = 823a5d3a1207c86ee49132824f046524		sample = 823a5d3a1207c86ee49132824f046524
	mask = abaaf34fdc		mask = abaaf34fdc
	header = caff00001d0008f067a5502a4262b5004074aaf2		header = caff00001d0008f067a5502a4262b5004074aaf2
	The final protected packet is then:		The final protected packet is then:
	c7ff00001d0008f067a5502a4262b500 4075fb12ff07823a5d24534d906ce4c7		c7ff00001f0008f067a5502a4262b500 4075fb12ff07823a5d24534d906ce4c7
	6782a2167e3479c0f7f6395dc2c91676 302fe6d70bb7cbeb117b4ddb7d173498		6782a2167e3479c0f7f6395dc2c91676 302fe6d70bb7cbeb117b4ddb7d173498
	44fd61dae200b8338e1b932976b61d91 e64a02e9e0ee72e3a6f63aba4ceeeec5		44fd61dae200b8338e1b932976b61d91 e64a02e9e0ee72e3a6f63aba4ceeeec5
	be2f24f2d86027572943533846caa13e 6f163fb257473dcca25396e88724f1e5		be2f24f2d86027572943533846caa13e 6f163fb257473d76f0e78487aca6427b
	d964dedee9b633		da2e7e70a7ee48
	A.4. Retry		A.4. Retry
	This shows a Retry packet that might be sent in response to the		This shows a Retry packet that might be sent in response to the
	Initial packet in Appendix A.2. The integrity check includes the		Initial packet in Appendix A.2. The integrity check includes the
	client-chosen connection ID value of 0x8394c8f03e515708, but that		client-chosen connection ID value of 0x8394c8f03e515708, but that
	value is not included in the final Retry packet:		value is not included in the final Retry packet:
	ffff00001d0008f067a5502a4262b574 6f6b656ed16926d81f6f9ca2953a8aa4		ffff00001f0008f067a5502a4262b574 6f6b656ec70ce5de430b4bdb7df1a383
	575e1e49		3a75f986
	A.5. ChaCha20-Poly1305 Short Header Packet		A.5. ChaCha20-Poly1305 Short Header Packet
	This example shows some of the steps required to protect a packet		This example shows some of the steps required to protect a packet
	with a short header. This example uses AEAD_CHACHA20_POLY1305.		with a short header. This example uses AEAD_CHACHA20_POLY1305.
	In this example, TLS produces an application write secret from which		In this example, TLS produces an application write secret from which
	a server uses HKDF-Expand-Label to produce four values: a key, an IV,		a server uses HKDF-Expand-Label to produce four values: a key, an IV,
	a header protection key, and the secret that will be used after keys		a header protection key, and the secret that will be used after keys
	are updated (this last value is not used further in this example).		are updated (this last value is not used further in this example).
	skipping to change at page 59, line 16 ¶		skipping to change at page 58, line 16 ¶
	attacker to gain a larger advantage in forging packets than the		attacker to gain a larger advantage in forging packets than the
	target of 2^-57.		target of 2^-57.
	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-29		C.1. Since draft-ietf-quic-tls-30
			* Add a new error code for AEAD_LIMIT_REACHED code to avoid conflict
			(#4087, #4088)
			C.2. Since draft-ietf-quic-tls-29
	* Updated limits on packet protection (#3788, #3789)		* Updated limits on packet protection (#3788, #3789)
	* Allow for packet processing to continue while waiting for TLS to		* Allow for packet processing to continue while waiting for TLS to
	provide keys (#3821, #3874)		provide keys (#3821, #3874)
	C.2. Since draft-ietf-quic-tls-28		C.3. Since draft-ietf-quic-tls-28
	* Defined limits on the number of packets that can be protected with		* Defined limits on the number of packets that can be protected with
	a single key and limits on the number of packets that can fail		a single key and limits on the number of packets that can fail
	authentication (#3619, #3620)		authentication (#3619, #3620)
	* Update Initial salt, Retry keys, and samples (#3711)		* Update Initial salt, Retry keys, and samples (#3711)
	C.3. Since draft-ietf-quic-tls-27		C.4. Since draft-ietf-quic-tls-27
	* Allowed CONNECTION_CLOSE in any packet number space, with		* Allowed CONNECTION_CLOSE in any packet number space, with
	restrictions on use of the application-specific variant (#3430,		restrictions on use of the application-specific variant (#3430,
	#3435, #3440)		#3435, #3440)
	* Prohibit the use of the compatibility mode from TLS 1.3 (#3594,		* Prohibit the use of the compatibility mode from TLS 1.3 (#3594,
	#3595)		#3595)
	C.4. Since draft-ietf-quic-tls-26		C.5. Since draft-ietf-quic-tls-26
	* No changes		* No changes
	C.5. Since draft-ietf-quic-tls-25		C.6. Since draft-ietf-quic-tls-25
	* No changes		* No changes
	C.6. Since draft-ietf-quic-tls-24		C.7. Since draft-ietf-quic-tls-24
	* Rewrite key updates (#3050)		* Rewrite key updates (#3050)
	- Allow but don't recommend deferring key updates (#2792, #3263)		- Allow but don't recommend deferring key updates (#2792, #3263)
	- More completely define received behavior (#2791)		- More completely define received behavior (#2791)
	- Define the label used with HKDF-Expand-Label (#3054)		- Define the label used with HKDF-Expand-Label (#3054)
	C.7. Since draft-ietf-quic-tls-23		C.8. Since draft-ietf-quic-tls-23
	* Key update text update (#3050):		* Key update text update (#3050):
	- Recommend constant-time key replacement (#2792)		- Recommend constant-time key replacement (#2792)
	- Provide explicit labels for key update key derivation (#3054)		- Provide explicit labels for key update key derivation (#3054)
	* Allow first Initial from a client to span multiple packets (#2928,		* Allow first Initial from a client to span multiple packets (#2928,
	#3045)		#3045)
	* PING can be sent at any encryption level (#3034, #3035)		* PING can be sent at any encryption level (#3034, #3035)
	C.8. Since draft-ietf-quic-tls-22		C.9. Since draft-ietf-quic-tls-22
	* Update the salt used for Initial secrets (#2887, #2980)		* Update the salt used for Initial secrets (#2887, #2980)
	C.9. Since draft-ietf-quic-tls-21		C.10. Since draft-ietf-quic-tls-21
	* No changes		* No changes
	C.10. Since draft-ietf-quic-tls-20		C.11. Since draft-ietf-quic-tls-20
	* Mandate the use of the QUIC transport parameters extension (#2528,		* Mandate the use of the QUIC transport parameters extension (#2528,
	#2560)		#2560)
	* Define handshake completion and confirmation; define clearer rules		* Define handshake completion and confirmation; define clearer rules
	when it encryption keys should be discarded (#2214, #2267, #2673)		when it encryption keys should be discarded (#2214, #2267, #2673)
	C.11. Since draft-ietf-quic-tls-18		C.12. Since draft-ietf-quic-tls-18
	* Increased the set of permissible frames in 0-RTT (#2344, #2355)		* Increased the set of permissible frames in 0-RTT (#2344, #2355)
	* Transport parameter extension is mandatory (#2528, #2560)		* Transport parameter extension is mandatory (#2528, #2560)
	C.12. Since draft-ietf-quic-tls-17		C.13. Since draft-ietf-quic-tls-17
	* Endpoints discard initial keys as soon as handshake keys are		* Endpoints discard initial keys as soon as handshake keys are
	available (#1951, #2045)		available (#1951, #2045)
	* Use of ALPN or equivalent is mandatory (#2263, #2284)		* Use of ALPN or equivalent is mandatory (#2263, #2284)
	C.13. Since draft-ietf-quic-tls-14		C.14. Since draft-ietf-quic-tls-14
	* Update the salt used for Initial secrets (#1970)		* Update the salt used for Initial secrets (#1970)
	* Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)		* Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
	* Change header protection		* Change header protection
	- Sample from a fixed offset (#1575, #2030)		- Sample from a fixed offset (#1575, #2030)
	- Cover part of the first byte, including the key phase (#1322,		- Cover part of the first byte, including the key phase (#1322,
	skipping to change at page 61, line 28 ¶		skipping to change at page 60, line 35 ¶
	* TLS provides an AEAD and KDF function (#2046)		* TLS provides an AEAD and KDF function (#2046)
	- Clarify that the TLS KDF is used with TLS (#1997)		- Clarify that the TLS KDF is used with TLS (#1997)
	- Change the labels for calculation of QUIC keys (#1845, #1971,		- Change the labels for calculation of QUIC keys (#1845, #1971,
	#1991)		#1991)
	* Initial keys are discarded once Handshake keys are available		* Initial keys are discarded once Handshake keys are available
	(#1951, #2045)		(#1951, #2045)
	C.14. Since draft-ietf-quic-tls-13		C.15. Since draft-ietf-quic-tls-13
	* Updated to TLS 1.3 final (#1660)		* Updated to TLS 1.3 final (#1660)
	C.15. Since draft-ietf-quic-tls-12		C.16. Since draft-ietf-quic-tls-12
	* Changes to integration of the TLS handshake (#829, #1018, #1094,		* Changes to integration of the TLS handshake (#829, #1018, #1094,
	#1165, #1190, #1233, #1242, #1252, #1450)		#1165, #1190, #1233, #1242, #1252, #1450)
	- The cryptographic handshake uses CRYPTO frames, not stream 0		- The cryptographic handshake uses CRYPTO frames, not stream 0
	- QUIC packet protection is used in place of TLS record		- QUIC packet protection is used in place of TLS record
	protection		protection
	- Separate QUIC packet number spaces are used for the handshake		- Separate QUIC packet number spaces are used for the handshake
	skipping to change at page 61, line 45 ¶		skipping to change at page 61, line 4 ¶
	#1165, #1190, #1233, #1242, #1252, #1450)		#1165, #1190, #1233, #1242, #1252, #1450)
	- The cryptographic handshake uses CRYPTO frames, not stream 0		- The cryptographic handshake uses CRYPTO frames, not stream 0
	- QUIC packet protection is used in place of TLS record		- QUIC packet protection is used in place of TLS record
	protection		protection
	- Separate QUIC packet number spaces are used for the handshake		- Separate QUIC packet number spaces are used for the handshake
	- Changed Retry to be independent of the cryptographic handshake		- Changed Retry to be independent of the cryptographic handshake
	- Limit the use of HelloRetryRequest to address TLS needs (like		- Limit the use of HelloRetryRequest to address TLS needs (like
	key shares)		key shares)
	* Changed codepoint of TLS extension (#1395, #1402)		* Changed codepoint of TLS extension (#1395, #1402)
	C.16. Since draft-ietf-quic-tls-11		C.17. Since draft-ietf-quic-tls-11
	* Encrypted packet numbers.		* Encrypted packet numbers.
	C.17. Since draft-ietf-quic-tls-10		C.18. Since draft-ietf-quic-tls-10
	* No significant changes.		* No significant changes.
	C.18. Since draft-ietf-quic-tls-09		C.19. Since draft-ietf-quic-tls-09
	* Cleaned up key schedule and updated the salt used for handshake		* Cleaned up key schedule and updated the salt used for handshake
	packet protection (#1077)		packet protection (#1077)
	C.19. Since draft-ietf-quic-tls-08		C.20. Since draft-ietf-quic-tls-08
	* Specify value for max_early_data_size to enable 0-RTT (#942)		* Specify value for max_early_data_size to enable 0-RTT (#942)
	* Update key derivation function (#1003, #1004)		* Update key derivation function (#1003, #1004)
	C.20. Since draft-ietf-quic-tls-07		C.21. Since draft-ietf-quic-tls-07
	* Handshake errors can be reported with CONNECTION_CLOSE (#608,		* Handshake errors can be reported with CONNECTION_CLOSE (#608,
	#891)		#891)
	C.21. Since draft-ietf-quic-tls-05		C.22. Since draft-ietf-quic-tls-05
	No significant changes.		No significant changes.
	C.22. Since draft-ietf-quic-tls-04		C.23. Since draft-ietf-quic-tls-04
	* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)		* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
	C.23. Since draft-ietf-quic-tls-03		C.24. Since draft-ietf-quic-tls-03
	No significant changes.		No significant changes.
	C.24. Since draft-ietf-quic-tls-02		C.25. Since draft-ietf-quic-tls-02
	* Updates to match changes in transport draft		* Updates to match changes in transport draft
	C.25. Since draft-ietf-quic-tls-01		C.26. Since draft-ietf-quic-tls-01
	* Use TLS alerts to signal TLS errors (#272, #374)		* Use TLS alerts to signal TLS errors (#272, #374)
	* Require ClientHello to fit in a single packet (#338)		* Require ClientHello to fit in a single packet (#338)
	* The second client handshake flight is now sent in the clear (#262,		* The second client handshake flight is now sent in the clear (#262,
	#337)		#337)
	* The QUIC header is included as AEAD Associated Data (#226, #243,		* The QUIC header is included as AEAD Associated Data (#226, #243,
	#302)		#302)
	skipping to change at page 63, line 21 ¶		skipping to change at page 62, line 30 ¶
	* Require at least TLS 1.3 (#138)		* Require at least TLS 1.3 (#138)
	* Define transport parameters as a TLS extension (#122)		* Define transport parameters as a TLS extension (#122)
	* Define handling for protected packets before the handshake		* Define handling for protected packets before the handshake
	completes (#39)		completes (#39)
	* Decouple QUIC version and ALPN (#12)		* Decouple QUIC version and ALPN (#12)
	C.26. Since draft-ietf-quic-tls-00		C.27. Since draft-ietf-quic-tls-00
	* Changed bit used to signal key phase		* Changed bit used to signal key phase
	* Updated key phase markings during the handshake		* Updated key phase markings during the handshake
	* Added TLS interface requirements section		* Added TLS interface requirements section
	* Moved to use of TLS exporters for key derivation		* Moved to use of TLS exporters for key derivation
	* Moved TLS error code definitions into this document		* Moved TLS error code definitions into this document
	C.27. Since draft-thomson-quic-tls-01		C.28. Since draft-thomson-quic-tls-01
	* Adopted as base for draft-ietf-quic-tls		* Adopted as base for draft-ietf-quic-tls
	* Updated authors/editors list		* Updated authors/editors list
	* Added status note		* Added status note
	Contributors		Contributors
	The IETF QUIC Working Group received an enormous amount of support		The IETF QUIC Working Group received an enormous amount of support
End of changes. 64 change blocks.
	209 lines changed or deleted		188 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/