draft-ietf-quic-tls-31.txt   draft-ietf-quic-tls-32.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: 29 March 2021 sn3rd Expires: 23 April 2021 sn3rd
25 September 2020 20 October 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-31 draft-ietf-quic-tls-32
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 29 March 2021. This Internet-Draft will expire on 23 April 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 46 skipping to change at page 2, line 46
4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 19
4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 20 4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 20
4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 20 4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 20
4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 21 4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 21
4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 21 4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 21
5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 21 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 22 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 22
5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 23 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 23
5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 25 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 25
5.4.1. Header Protection Application . . . . . . . . . . . . 25 5.4.1. Header Protection Application . . . . . . . . . . . . 26
5.4.2. Header Protection Sample . . . . . . . . . . . . . . 27 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 27
5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 29 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 29
5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 29 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 29
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 29 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 30
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30
5.7. Receiving Out-of-Order Protected Packets . . . . . . . . 30 5.7. Receiving Out-of-Order Protected Packets . . . . . . . . 31
5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 32 5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 32
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 33 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 34 6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 34
6.2. Responding to a Key Update . . . . . . . . . . . . . . . 35 6.2. Responding to a Key Update . . . . . . . . . . . . . . . 35
6.3. Timing of Receive Key Generation . . . . . . . . . . . . 36 6.3. Timing of Receive Key Generation . . . . . . . . . . . . 36
6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 37 6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 37
6.5. Receiving with Different Keys . . . . . . . . . . . . . . 37 6.5. Receiving with Different Keys . . . . . . . . . . . . . . 37
6.6. Limits on AEAD Usage . . . . . . . . . . . . . . . . . . 38 6.6. Limits on AEAD Usage . . . . . . . . . . . . . . . . . . 38
6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 40 6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 40
7. Security of Initial Messages . . . . . . . . . . . . . . . . 40 7. Security of Initial Messages . . . . . . . . . . . . . . . . 40
8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 40 8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 40
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 41 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 41
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 41 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 41
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 42 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 42
8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 42 8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 42 9. Security Considerations . . . . . . . . . . . . . . . . . . . 43
9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 43 9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 43
9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 43 9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 43
9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 44 9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 44
9.4. Header Protection Analysis . . . . . . . . . . . . . . . 44 9.4. Header Protection Analysis . . . . . . . . . . . . . . . 44
9.5. Header Protection Timing Side-Channels . . . . . . . . . 45 9.5. Header Protection Timing Side-Channels . . . . . . . . . 45
9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 46 9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 46
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. Normative References . . . . . . . . . . . . . . . . . . 46 11.1. Normative References . . . . . . . . . . . . . . . . . . 46
11.2. Informative References . . . . . . . . . . . . . . . . . 48 11.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 49 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 49
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 50 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 50
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 52 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 52
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 53 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 53 A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 53
Appendix B. AEAD Algorithm Analysis . . . . . . . . . . . . . . 55 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 . . . . . . . . . . . . . . . . . . . . . . . . . 55 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 56
B.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 56 B.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 56
B.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 56 B.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 56
B.2. Analysis of AEAD_AES_128_CCM Usage Limits . . . . . . . . 57 B.2. Analysis of AEAD_AES_128_CCM Usage Limits . . . . . . . . 57
B.2.1. Confidentiality Limits . . . . . . . . . . . . . . . 57
B.2.2. Integrity Limits . . . . . . . . . . . . . . . . . . 57
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 58 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 58
C.1. Since draft-ietf-quic-tls-30 . . . . . . . . . . . . . . 58 C.1. Since draft-ietf-quic-tls-31 . . . . . . . . . . . . . . 58
C.2. Since draft-ietf-quic-tls-29 . . . . . . . . . . . . . . 58 C.2. Since draft-ietf-quic-tls-30 . . . . . . . . . . . . . . 58
C.3. Since draft-ietf-quic-tls-28 . . . . . . . . . . . . . . 58 C.3. Since draft-ietf-quic-tls-29 . . . . . . . . . . . . . . 58
C.4. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 58 C.4. Since draft-ietf-quic-tls-28 . . . . . . . . . . . . . . 58
C.5. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 58 C.5. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 59
C.6. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 59 C.6. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 59
C.7. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 59 C.7. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 59
C.8. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 59 C.8. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 59
C.9. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 59 C.9. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 59
C.10. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 59 C.10. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 59
C.11. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 59 C.11. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 59
C.12. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 59 C.12. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 60
C.13. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 60 C.13. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 60
C.14. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 60 C.14. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 60
C.15. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 60 C.15. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 60
C.16. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 60 C.16. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 60
C.17. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 61 C.17. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 61
C.18. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 61 C.18. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 61
C.19. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 61 C.19. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 61
C.20. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 61 C.20. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 61
C.21. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 61 C.21. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 61
C.22. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 61 C.22. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 61
C.23. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 61 C.23. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 61
C.24. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 61 C.24. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 62
C.25. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 61 C.25. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 62
C.26. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 62 C.26. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 62
C.27. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 62 C.27. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 62
C.28. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 62 C.28. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 62
C.29. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 63
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 5, line 11 skipping to change at page 5, line 11
capitals, as shown here. capitals, as shown here.
This document uses the terminology established in [QUIC-TRANSPORT]. This document uses the terminology established in [QUIC-TRANSPORT].
For brevity, the acronym TLS is used to refer to TLS 1.3, though a For brevity, the acronym TLS is used to refer to TLS 1.3, though a
newer version could be used; see Section 4.2. newer version could be used; see Section 4.2.
2.1. TLS Overview 2.1. TLS Overview
TLS provides two endpoints with a way to establish a means of TLS provides two endpoints with a way to establish a means of
communication over an untrusted medium (that is, the Internet) that communication over an untrusted medium (that is, the Internet). TLS
ensures that messages they exchange cannot be observed, modified, or enables authentication of peers and provides confidentiality and
forged. integrity protection for messages that endpoints exchange.
Internally, TLS is a layered protocol, with the structure shown in Internally, TLS is a layered protocol, with the structure shown in
Figure 1. Figure 1.
+-------------+------------+--------------+---------+ +-------------+------------+--------------+---------+
Handshake | | | Application | | Handshake | | | Application | |
Layer | Handshake | Alerts | Data | ... | Layer | Handshake | Alerts | Data | ... |
| | | | | | | | | |
+-------------+------------+--------------+---------+ +-------------+------------+--------------+---------+
Record | | Record | |
skipping to change at page 6, line 19 skipping to change at page 6, line 19
TLS provides two basic handshake modes of interest to QUIC: TLS provides two basic handshake modes of interest to QUIC:
* A full 1-RTT handshake, in which the client is able to send * A full 1-RTT handshake, in which the client is able to send
Application Data after one round trip and the server immediately Application Data after one round trip and the server immediately
responds after receiving the first handshake message from the responds after receiving the first handshake message from the
client. client.
* A 0-RTT handshake, in which the client uses information it has * A 0-RTT handshake, in which the client uses information it has
previously learned about the server to send Application Data previously learned about the server to send Application Data
immediately. This Application Data can be replayed by an attacker immediately. This Application Data can be replayed by an attacker
so it MUST NOT carry a self-contained trigger for any non- so 0-RTT is not suitable for carrying instructions that might
idempotent action. initiate any non-idempotent action.
A simplified TLS handshake with 0-RTT application data is shown in A simplified TLS handshake with 0-RTT application data is shown in
Figure 2. Figure 2.
Client Server Client Server
ClientHello ClientHello
(0-RTT Application Data) --------> (0-RTT Application Data) -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
skipping to change at page 22, line 40 skipping to change at page 22, line 40
Each encryption level has separate secret values for protection of Each encryption level has separate secret values for protection of
packets sent in each direction. These traffic secrets are derived by packets sent in each direction. These traffic secrets are derived by
TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all
encryption levels except the Initial encryption level. The secrets encryption levels except the Initial encryption level. The secrets
for the Initial encryption level are computed based on the client's for the Initial encryption level are computed based on the client's
initial Destination Connection ID, as described in Section 5.2. initial Destination Connection ID, as described in Section 5.2.
The keys used for packet protection are computed from the TLS secrets The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of [TLS13] is used, using the hash function described in Section 7.1 of [TLS13] is used, using the hash
function from the negotiated cipher suite. Other versions of TLS function from the negotiated cipher suite. Note that labels, which
MUST provide a similar function in order to be used with QUIC. are described using strings, are encoded as bytes using ASCII [ASCII]
without quotes or any trailing NUL byte. Other versions of TLS MUST
provide a similar function in order to be used with QUIC.
The current encryption level secret and the label "quic key" are The current encryption level secret and the label "quic key" are
input to the KDF to produce the AEAD key; the label "quic iv" is used input to the KDF to produce the AEAD key; the label "quic iv" is used
to derive the Initialization Vector (IV); see Section 5.3. The to derive the Initialization Vector (IV); see Section 5.3. The
header protection key uses the "quic hp" label; see Section 5.4. header protection key uses the "quic hp" label; see Section 5.4.
Using these labels provides key separation between QUIC and TLS; see Using these labels provides key separation between QUIC and TLS; see
Section 9.6. Section 9.6.
The KDF used for initial secrets is always the HKDF-Expand-Label The KDF used for initial secrets is always the HKDF-Expand-Label
function from TLS 1.3; see Section 5.2. function from TLS 1.3; see Section 5.2.
skipping to change at page 23, line 19 skipping to change at page 23, line 22
first Initial packet. first Initial packet.
This secret is determined by using HKDF-Extract (see Section 2.2 of This secret is determined by using HKDF-Extract (see Section 2.2 of
[HKDF]) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and [HKDF]) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and
a IKM of the Destination Connection ID field. This produces an a IKM of the Destination Connection ID field. This produces an
intermediate pseudorandom key (PRK) that is used to derive two intermediate pseudorandom key (PRK) that is used to derive two
separate secrets for sending and receiving. separate secrets for sending and receiving.
The secret used by clients to construct Initial packets uses the PRK The secret used by clients to construct Initial packets uses the PRK
and the label "client in" as input to the HKDF-Expand-Label function and the label "client in" as input to the HKDF-Expand-Label function
to produce a 32 byte secret; packets constructed by the server use from TLS [TLS13] to produce a 32-byte secret. Packets constructed by
the same process with the label "server in". The hash function for the server use the same process with the label "server in". The hash
HKDF when deriving initial secrets and keys is SHA-256 [SHA]. function for HKDF when deriving initial secrets and keys is SHA-256
[SHA].
This process in pseudocode is: This process in pseudocode is:
initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899 initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899
initial_secret = HKDF-Extract(initial_salt, initial_secret = HKDF-Extract(initial_salt,
client_dst_connection_id) client_dst_connection_id)
client_initial_secret = HKDF-Expand-Label(initial_secret, client_initial_secret = HKDF-Expand-Label(initial_secret,
"client in", "", "client in", "",
Hash.length) Hash.length)
skipping to change at page 24, line 11 skipping to change at page 24, line 15
The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
Initial packets even where the TLS versions offered do not include Initial packets even where the TLS versions offered do not include
TLS 1.3. TLS 1.3.
The secrets used for constructing Initial packets change when a The secrets used for constructing Initial packets change when a
server sends a Retry packet to use the connection ID value selected server sends a Retry packet to use the connection ID value selected
by the server. The secrets do not change when a client changes the by the server. The secrets do not change when a client changes the
Destination Connection ID it uses in response to an Initial packet Destination Connection ID it uses in response to an Initial packet
from the server. from the server.
Note: The Destination Connection ID is of arbitrary length, and it Note: The Destination Connection ID field could be any length up to
could be zero length if the server sends a Retry packet with a 20 bytes, including zero length if the server sends a Retry packet
zero-length Source Connection ID field. In this case, the Initial with a zero-length Source Connection ID field. After a Retry, the
keys provide no assurance to the client that the server received Initial keys provide the client no assurance that the server
its packet; the client has to rely on the exchange that included received its packet, so the client has to rely on the exchange
the Retry packet for that property. that included the Retry packet to validate the server address; see
Section 8.1 of [QUIC-TRANSPORT].
Appendix A contains sample Initial packets. Appendix A contains sample Initial packets.
5.3. AEAD Usage 5.3. AEAD Usage
The Authenticated Encryption with Associated Data (AEAD; see [AEAD]) The Authenticated Encryption with Associated Data (AEAD; see [AEAD])
function used for QUIC packet protection is the AEAD that is function used for QUIC packet protection is the AEAD that is
negotiated for use with the TLS connection. For example, if TLS is negotiated for use with the TLS connection. For example, if TLS is
using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM
function is used. function is used.
skipping to change at page 26, line 31 skipping to change at page 26, line 38
packet[0] ^= mask[0] & 0x0f packet[0] ^= mask[0] & 0x0f
else: else:
# Short header: 5 bits masked # Short header: 5 bits masked
packet[0] ^= mask[0] & 0x1f packet[0] ^= mask[0] & 0x1f
# pn_offset is the start of the Packet Number field. # pn_offset is the start of the Packet Number field.
packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length] packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
Figure 6: Header Protection Pseudocode Figure 6: Header Protection Pseudocode
Specific header protection functions are defined based on the
selected cipher suite; see Section 5.4.3 and Section 5.4.4.
Figure 7 shows an example long header packet (Initial) and a short Figure 7 shows an example long header packet (Initial) and a short
header packet. Figure 7 shows the fields in each header that are header packet. Figure 7 shows the fields in each header that are
covered by header protection and the portion of the protected packet covered by header protection and the portion of the protected packet
payload that is sampled. payload that is sampled.
Initial Packet { Initial Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 0, Long Packet Type (2) = 0,
Reserved Bits (2), # Protected Reserved Bits (2), # Protected
skipping to change at page 29, line 14 skipping to change at page 29, line 14
5.4.3. AES-Based Header Protection 5.4.3. AES-Based Header Protection
This section defines the packet protection algorithm for This section defines the packet protection algorithm for
AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM.
AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES in electronic AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES in electronic
code-book (ECB) mode. AEAD_AES_256_GCM uses 256-bit AES in ECB mode. code-book (ECB) mode. AEAD_AES_256_GCM uses 256-bit AES in ECB mode.
AES is defined in [AES]. AES is defined in [AES].
This algorithm samples 16 bytes from the packet ciphertext. This This algorithm samples 16 bytes from the packet ciphertext. This
value is used as the input to AES-ECB. In pseudocode: value is used as the input to AES-ECB. In pseudocode, the header
protection function is defined as:
mask = AES-ECB(hp_key, sample) header_protection(hp_key, sample):
mask = AES-ECB(hp_key, sample)
5.4.4. ChaCha20-Based Header Protection 5.4.4. ChaCha20-Based Header Protection
When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw
ChaCha20 function as defined in Section 2.4 of [CHACHA]. This uses a ChaCha20 function as defined in Section 2.4 of [CHACHA]. This uses a
256-bit key and 16 bytes sampled from the packet protection output. 256-bit key and 16 bytes sampled from the packet protection output.
The first 4 bytes of the sampled ciphertext are the block counter. A The first 4 bytes of the sampled ciphertext are the block counter. A
ChaCha20 implementation could take a 32-bit integer in place of a ChaCha20 implementation could take a 32-bit integer in place of a
byte sequence, in which case the byte sequence is interpreted as a byte sequence, in which case the byte sequence is interpreted as a
little-endian value. little-endian value.
The remaining 12 bytes are used as the nonce. A ChaCha20 The remaining 12 bytes are used as the nonce. A ChaCha20
implementation might take an array of three 32-bit integers in place implementation might take an array of three 32-bit integers in place
of a byte sequence, in which case the nonce bytes are interpreted as of a byte sequence, in which case the nonce bytes are interpreted as
a sequence of 32-bit little-endian integers. a sequence of 32-bit little-endian integers.
The encryption mask is produced by invoking ChaCha20 to protect 5 The encryption mask is produced by invoking ChaCha20 to protect 5
zero bytes. In pseudocode: zero bytes. In pseudocode, the header protection function is defined
as:
counter = sample[0..3] header_protection(hp_key, sample):
nonce = sample[4..15] counter = sample[0..3]
mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0}) nonce = sample[4..15]
mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})
5.5. Receiving Protected Packets 5.5. 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 in the same packet number space number, it MUST discard all packets in the same packet number space
with higher packet numbers if they cannot be successfully unprotected with higher packet numbers if they cannot be successfully unprotected
with either the same key, or - if there is a key update - the next with either the same key, or - if there is a key update - the next
packet protection key (see Section 6). Similarly, a packet that packet protection key (see Section 6). Similarly, a packet that
appears to trigger a key update, but cannot be unprotected appears to trigger a key update, but cannot be unprotected
successfully MUST be discarded. successfully MUST be discarded.
skipping to change at page 37, line 12 skipping to change at page 37, line 19
effort - triggering this process could be used by an attacker for effort - triggering this process could be used by an attacker for
DoS. DoS.
For this reason, endpoints MUST be able to retain two sets of packet For this reason, endpoints MUST be able to retain two sets of packet
protection keys for receiving packets: the current and the next. protection keys for receiving packets: the current and the next.
Retaining the previous keys in addition to these might improve Retaining the previous keys in addition to these might improve
performance, but this is not essential. performance, but this is not essential.
6.4. Sending with Updated Keys 6.4. Sending with Updated Keys
An endpoint always sends packets that are protected with the newest An endpoint never sends packets that are protected with old keys.
keys. Keys used for packet protection can be discarded immediately Only the current keys are used. Keys used for protecting packets can
after switching to newer keys. be discarded immediately after switching to newer keys.
Packets with higher packet numbers MUST be protected with either the Packets with higher packet numbers MUST be protected with either the
same or newer packet protection keys than packets with lower packet same or newer packet protection keys than packets with lower packet
numbers. An endpoint that successfully removes protection with old numbers. An endpoint that successfully removes protection with old
keys when newer keys were used for packets with lower packet numbers keys when newer keys were used for packets with lower packet numbers
MUST treat this as a connection error of type KEY_UPDATE_ERROR. MUST treat this as a connection error of type KEY_UPDATE_ERROR.
6.5. Receiving with Different Keys 6.5. Receiving with Different Keys
For receiving packets during a key update, packets protected with For receiving packets during a key update, packets protected with
skipping to change at page 39, line 18 skipping to change at page 39, line 18
MUST stop using those keys. Endpoints MUST initiate a key update MUST stop using those keys. Endpoints MUST initiate a key update
before sending more protected packets than the confidentiality limit before sending more protected packets than the confidentiality limit
for the selected AEAD permits. If a key update is not possible or for the selected AEAD permits. If a key update is not possible or
integrity limits are reached, the endpoint MUST stop using the integrity limits are reached, the endpoint MUST stop using the
connection and only send stateless resets in response to receiving connection and only send stateless resets in response to receiving
packets. It is RECOMMENDED that endpoints immediately close the packets. It is RECOMMENDED that endpoints immediately close the
connection with a connection error of type AEAD_LIMIT_REACHED before connection with a connection error of type AEAD_LIMIT_REACHED before
reaching a state where key updates are not possible. reaching a state where key updates are not possible.
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
is 2^25 encrypted packets; see Appendix B.1. For is 2^23 encrypted packets; see Appendix B.1. For
AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
number of possible packets (2^62) and so can be disregarded. For number of possible packets (2^62) and so can be disregarded. For
AEAD_AES_128_CCM, the confidentiality limit is 2^23.5 encrypted AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
packets; see Appendix B.2. Applying a limit reduces the probability packets; see Appendix B.2. Applying a limit reduces the probability
that an attacker can distinguish the AEAD in use from a random that an attacker can distinguish the AEAD in use from a random
permutation; see [AEBounds], [ROBUST], and [GCM-MU]. permutation; see [AEBounds], [ROBUST], and [GCM-MU].
In addition to counting packets sent, endpoints MUST count the number In addition to counting packets sent, endpoints MUST count the number
of received packets that fail authentication during the lifetime of a of received packets that fail authentication during the lifetime of a
connection. If the total number of received packets that fail connection. If the total number of received packets that fail
authentication within the connection, across all keys, exceeds the authentication within the connection, across all keys, exceeds the
integrity limit for the selected AEAD, the endpoint MUST immediately integrity limit for the selected AEAD, the endpoint MUST immediately
close the connection with a connection error of type close the connection with a connection error of type
AEAD_LIMIT_REACHED and not process any more packets. AEAD_LIMIT_REACHED and not process any more packets.
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is
2^54 invalid packets; see Appendix B.1. For AEAD_CHACHA20_POLY1305, 2^52 invalid packets; see Appendix B.1. For AEAD_CHACHA20_POLY1305,
the integrity limit is 2^36 invalid packets; see [AEBounds]. For the integrity limit is 2^36 invalid packets; see [AEBounds]. For
AEAD_AES_128_CCM, the integrity limit is 2^23.5 invalid packets; see AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see
Appendix B.2. Applying this limit reduces the probability that an Appendix B.2. Applying this limit reduces the probability that an
attacker can successfully forge a packet; see [AEBounds], [ROBUST], attacker can successfully forge a packet; see [AEBounds], [ROBUST],
and [GCM-MU]. and [GCM-MU].
Endpoints that limit the size of packets MAY use higher
confidentiality and integrity limits; see Appendix B for details.
Future analyses and specifications MAY relax confidentiality or Future analyses and specifications MAY relax confidentiality or
integrity limits for an AEAD. integrity limits for an AEAD.
Note: These limits were originally calculated using assumptions Note: These limits were originally calculated using assumptions
about the limits on TLS record size. The maximum size of a TLS about the limits on TLS record size. The maximum size of a TLS
record is 2^14 bytes. In comparison, QUIC packets can be up to record is 2^14 bytes. In comparison, QUIC packets can be up to
2^16 bytes. However, it is expected that QUIC packets will 2^16 bytes. However, it is expected that QUIC packets will
generally be smaller than TLS records. Where packets might be generally be smaller than TLS records. Where packets might be
larger than 2^14 bytes in length, smaller limits might be needed. larger than 2^14 bytes in length, smaller limits might be needed.
skipping to change at page 47, line 27 skipping to change at page 47, line 31
<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-31, 25 September 2020, draft-ietf-quic-recovery-32, 20 October 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-31>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-32>.
[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-31, 25 September Internet-Draft, draft-ietf-quic-transport-32, 20 October
2020, <https://tools.ietf.org/html/draft-ietf-quic- 2020, <https://tools.ietf.org/html/draft-ietf-quic-
transport-31>. transport-32>.
[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>.
skipping to change at page 48, line 20 skipping to change at page 48, line 25
[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", 8 March 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>.
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[CCM-ANALYSIS] [CCM-ANALYSIS]
Jonsson, J., "On the Security of CTR + CBC-MAC", Selected Jonsson, J., "On the Security of CTR + CBC-MAC", Selected
Areas in Cryptography pp. 76-93, Areas in Cryptography pp. 76-93,
DOI 10.1007/3-540-36492-7_7, 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, 6 January 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-
skipping to change at page 49, line 8 skipping to change at page 49, line 17
November 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", Advances in Cryptology - CRYPTO 2019 pp. AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
235-265, DOI 10.1007/978-3-030-26948-7_9, 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-31, 25 September 2020, quic-http-32, 20 October 2020,
<https://tools.ietf.org/html/draft-ietf-quic-http-31>. <https://tools.ietf.org/html/draft-ietf-quic-http-32>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 51, line 17 skipping to change at page 51, line 17
616d706c652e636f6dff01000100000a 00080006001d00170018001000070005 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400 baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
0d0010000e0403050306030203080408 050806002d00020101001c00024001ff 0d0010000e0403050306030203080408 050806002d00020101001c00024001ff
a500320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 a500320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff 75300901100f088394c8f03e51570806 048000ffff
The unprotected header includes the connection ID and a 4-byte packet The unprotected header includes the connection ID and a 4-byte packet
number encoding for a packet number of 2: number encoding for a packet number of 2:
c3ff00001d088394c8f03e5157080000449e00000002 c3ff000020088394c8f03e5157080000449e00000002
Protecting the payload produces output that is sampled for header Protecting the payload produces output that is sampled for header
protection. Because the header uses a 4-byte packet number encoding, protection. Because the header uses a 4-byte packet number encoding,
the first 16 bytes of the protected payload is sampled, then applied the first 16 bytes of the protected payload is sampled, then applied
to the header: to the header:
sample = fb66bc6a93032b50dd8973972d149421 sample = fb66bc6a93032b50dd8973972d149421
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 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 = cdff000020088394c8f03e5157080000449e9cdb990b
The resulting protected packet is: The resulting protected packet is:
cdff00001f088394c8f03e5157080000 449e9cdb990bfb66bc6a93032b50dd89 cdff000020088394c8f03e5157080000 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 52, 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
395781bc0a3e8125b4dd506ca025eb37 b5a464ca5b62df3be35ee0d0a2ec68f3
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
The header from the server includes a new connection ID and a 2-byte The header from the server includes a new connection ID and a 2-byte
packet number encoding for a packet number of 1: packet number encoding for a packet number of 1:
c1ff00001d0008f067a5502a4262b50040740001 c1ff0000200008f067a5502a4262b50040750001
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 = 823a5d24534d906ce4c76782a2167e34
mask = abaaf34fdc mask = abaaf34fdc
header = caff00001d0008f067a5502a4262b5004074aaf2 header = c7ff0000200008f067a5502a4262b5004075fb12
The final protected packet is then: The final protected packet is then:
c7ff00001f0008f067a5502a4262b500 4075fb12ff07823a5d24534d906ce4c7 c7ff0000200008f067a5502a4262b500 4075fb12ff07823a5d24534d906ce4c7
6782a2167e3479c0f7f6395dc2c91676 302fe6d70bb7cbeb117b4ddb7d173498 6782a2167e3479c0f7f6395dc2c91676 302fe6d70bb7cbeb117b4ddb7d173498
44fd61dae200b8338e1b932976b61d91 e64a02e9e0ee72e3a6f63aba4ceeeec5 44fd61dae200b8338e1b932976b61d91 e64a02e9e0ee72e3a6f63aba4ceeeec5
be2f24f2d86027572943533846caa13e 6f163fb257473d76f0e78487aca6427b be2f24f2d86027572943533846caa13e 6f163fb257473d0eda5047360fd4a47e
da2e7e70a7ee48 fd8142fafc0f76
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:
ffff00001f0008f067a5502a4262b574 6f6b656ec70ce5de430b4bdb7df1a383 ffff0000200008f067a5502a4262b574 6f6b656e59756519dd6cc85bd90e33a9
3a75f986 34d2ff85
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 55, line 13 skipping to change at page 55, line 13
packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb
Appendix B. AEAD Algorithm Analysis Appendix B. AEAD Algorithm Analysis
This section documents analyses used in deriving AEAD algorithm This section documents analyses used in deriving AEAD algorithm
limits for AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. limits for AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM.
The analyses that follow use symbols for multiplication (*), division The analyses that follow use symbols for multiplication (*), division
(/), and exponentiation (^), plus parentheses for establishing (/), and exponentiation (^), plus parentheses for establishing
precedence. The following symbols are also used: precedence. The following symbols are also used:
t: The size of the authentication tag in bits. For this cipher, t t: The size of the authentication tag in bits. For these ciphers, t
is 128. is 128.
n: The size of the block function in bits. For this cipher, n is n: The size of the block function in bits. For these ciphers, n is
128. 128.
k: The size of the key in bits. This is 128 for AEAD_AES_128_GCM
and AEAD_AES_128_CCM; 256 for AEAD_AES_256_GCM.
l: The number of blocks in each packet (see below). l: The number of blocks in each packet (see below).
q: The number of genuine packets created and protected by endpoints. q: The number of genuine packets created and protected by endpoints.
This value is the bound on the number of packets that can be This value is the bound on the number of packets that can be
protected before updating keys. protected before updating keys.
v: The number of forged packets that endpoints will accept. This v: The number of forged packets that endpoints will accept. This
value is the bound on the number of forged packets that an value is the bound on the number of forged packets that an
endpoint can reject before updating keys. endpoint can reject before updating keys.
o: The amount of offline ideal cipher queries made by an adversary. o: The amount of offline ideal cipher queries made by an adversary.
The analyses that follow rely on a count of the number of block The analyses that follow rely on a count of the number of block
operations involved in producing each message. For simplicity, and operations involved in producing each message. This analysis is
to match the analysis of other AEAD functions in [AEBounds], this performed for packets of size up to 2^11 (l = 2^7) and 2^16 (l =
analysis assumes a packet length of 2^10 blocks; that is, a packet 2^12). A size of 2^11 is expected to be a limit that matches common
size limit of 2^14 bytes. deployment patterns, whereas the 2^16 is the maximum possible size of
a QUIC packet. Only endpoints that strictly limit packet size can
use the larger confidentiality and integrity limits that are derived
using the smaller packet size.
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is
the length of the associated data in blocks plus the length of the
plaintext in blocks.
For AEAD_AES_128_CCM, the total number of block cipher operations is For AEAD_AES_128_CCM, the total number of block cipher operations is
the sum of: the length of the associated data in blocks, the length the sum of: the length of the associated data in blocks, the length
of the ciphertext in blocks, the length of the plaintext in blocks, of the ciphertext in blocks, the length of the plaintext in blocks,
plus 1. In this analysis, this is simplified to a value of twice the plus 1. In this analysis, this is simplified to a value of twice the
length of the packet in blocks (that is, "2l = 2^11"). This length of the packet in blocks (that is, "2l = 2^8" for packets that
are limited to 2^11 bytes, or "2l = 2^13" otherwise). This
simplification is based on the packet containing all of the simplification is based on the packet containing all of the
associated data and ciphertext. This results in a negligible 1 to 3 associated data and ciphertext. This results in a 1 to 3 block
block overestimation of the number of operations. overestimation of the number of operations per packet.
B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits
[GCM-MU] specify concrete bounds for AEAD_AES_128_GCM and [GCM-MU] specify concrete bounds for AEAD_AES_128_GCM and
AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents
this analysis using several simplifying assumptions: this analysis using several simplifying assumptions:
* The number of ciphertext blocks an attacker uses in forgery * The number of ciphertext blocks an attacker uses in forgery
attempts is bounded by v * l, the number of forgery attempts and attempts is bounded by v * l, the number of forgery attempts and
the size of each packet (in blocks). the size of each packet (in blocks).
skipping to change at page 56, line 23 skipping to change at page 56, line 32
in [AEBounds], which allows for larger limits than those described in in [AEBounds], which allows for larger limits than those described in
[TLS13]. [TLS13].
B.1.1. Confidentiality Limit B.1.1. Confidentiality Limit
For confidentiality, Theorum (4.3) in [GCM-MU] establishes that - for For confidentiality, Theorum (4.3) in [GCM-MU] establishes that - for
a single user that does not repeat nonces - the dominant term in a single user that does not repeat nonces - the dominant term in
determining the distinguishing advantage between a real and random determining the distinguishing advantage between a real and random
AEAD algorithm gained by an attacker is: AEAD algorithm gained by an attacker is:
2 * (q * l)^2 / 2^128 2 * (q * l)^2 / 2^n
For a target advantage of 2^-57, this results in the relation: For a target advantage of 2^-57, this results in the relation:
q <= 2^25 q <= 2^35 / l
Thus, endpoints cannot protect more than 2^25 packets in a single Thus, endpoints that do not send packets larger than 2^11 bytes
connection without causing an attacker to gain an larger advantage cannot protect more than 2^28 packets in a single connection without
than the target of 2^-57. causing an attacker to gain an larger advantage than the target of
2^-57. The limit for endpoints that allow for the packet size to be
as large as 2^16 is instead 2^23.
B.1.2. Integrity Limit B.1.2. Integrity Limit
For integrity, Theorem (4.3) in [GCM-MU] establishes that an attacker For integrity, Theorem (4.3) in [GCM-MU] establishes that an attacker
gains an advantage in successfully forging a packet of no more than: gains an advantage in successfully forging a packet of no more than:
(1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n)) (1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n))
+ ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k) + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k)
The goal is to limit this advantage to 2^-57. For AEAD_AES_128_GCM, The goal is to limit this advantage to 2^-57. For AEAD_AES_128_GCM,
the fourth term in this inequality dominates the rest, so the others the fourth term in this inequality dominates the rest, so the others
can be removed without significant effect on the result. This can be removed without significant effect on the result. This
produces the following approximation: produces the following approximation:
v <= 2^54 v <= 2^64 / l
For AEAD_AES_256_GCM, the second and fourth terms dominate the rest, Endpoints that do not attempt to remove protection from packets
so the others can be removed without affecting the result. This larger than 2^11 bytes can attempt to remove protection from at most
produces the following approximation: 2^57 packets. Endpoints that do not restrict the size of processed
packets can attempt to remove protection from at most 2^52 packets.
For AEAD_AES_256_GCM, the same term dominates, but the larger value
of k produces the following approximation:
v <= 2^192 / l
v <= 2^182
This is substantially larger than the limit for AEAD_AES_128_GCM. This is substantially larger than the limit for AEAD_AES_128_GCM.
However, this document recommends that the same limit be applied to However, this document recommends that the same limit be applied to
both functions as either limit is acceptably large. both functions as either limit is acceptably large.
B.2. Analysis of AEAD_AES_128_CCM Usage Limits B.2. Analysis of AEAD_AES_128_CCM Usage Limits
TLS [TLS13] and [AEBounds] do not specify limits on usage for TLS [TLS13] and [AEBounds] do not specify limits on usage for
AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires
limits on use that ensure that both confidentiality and integrity are limits on use that ensure that both confidentiality and integrity are
preserved. This section documents that analysis. preserved. This section documents that analysis.
[CCM-ANALYSIS] is used as the basis of this analysis. The results of [CCM-ANALYSIS] is used as the basis of this analysis. The results of
that analysis are used to derive usage limits that are based on those that analysis are used to derive usage limits that are based on those
chosen in [TLS13]. chosen in [TLS13].
B.2.1. Confidentiality Limits
For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an
attacker gains a distinguishing advantage over an ideal pseudorandom attacker gains a distinguishing advantage over an ideal pseudorandom
permutation (PRP) of no more than: permutation (PRP) of no more than:
(2l * q)^2 / 2^n (2l * q)^2 / 2^n
For a target advantage of 2^-57, this results in the relation: The integrity limit in Theorem 1 in [CCM-ANALYSIS] provides an
attacker a strictly higher advantage for the same number of messages.
q <= 2^24.5 As the targets for the confidentiality advantage and the integrity
advantage are the same, only Theorem 1 needs to be considered.
That is, endpoints cannot protect more than 2^23 packets with the
same set of keys without causing an attacker to gain a larger
advantage than the target of 2^-57. Note however that the integrity
limits further constrain this value.
B.2.2. Integrity Limits
For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an Theorem 1 establishes that an attacker gains an advantage over an
attacker gains an advantage over an ideal PRP of no more than: ideal PRP of no more than:
v / 2^t + (2l * (v + q))^2 / 2^n v / 2^t + (2l * (v + q))^2 / 2^n
As "t" and "n" are both 128, the first term is negligible relative to
the second, so that term can be removed without a significant effect
on the result.
The goal is to limit this advantage to 2^-57. As "t" and "n" are This produces a relation that combines both encryption and decryption
both 128, the first term is negligible relative to the second, so attempts with the same limit as that produced by the theorem for
that term can be removed without a significant effect on the result. confidentiality alone. For a target advantage of 2^-57, this results
This produces the relation: in:
v + q <= 2^24.5 v + q <= 2^34.5 / l
Assuming "q = v", endpoints cannot attempt to protect or authenticate
more than 2^23.5 packets with the same set of keys without causing an By setting "q = v", values for both confidentiality and integrity
attacker to gain a larger advantage in forging packets than the limits can be produced. Endpoints that limit packets to 2^11 bytes
target of 2^-57. therefore have both confidentiality and integrity limits of 2^26.5
packets. Endpoints that do not restrict packet size have a limit of
2^21.5.
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-30 C.1. Since draft-ietf-quic-tls-31
* Packet protection limits are based on maximum-sized packets;
improved analysis (#3701, #4175)
C.2. Since draft-ietf-quic-tls-30
* Add a new error code for AEAD_LIMIT_REACHED code to avoid conflict * Add a new error code for AEAD_LIMIT_REACHED code to avoid conflict
(#4087, #4088) (#4087, #4088)
C.2. Since draft-ietf-quic-tls-29 C.3. 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.3. Since draft-ietf-quic-tls-28 C.4. 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.4. Since draft-ietf-quic-tls-27 C.5. 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.5. Since draft-ietf-quic-tls-26 C.6. Since draft-ietf-quic-tls-26
* No changes * No changes
C.6. Since draft-ietf-quic-tls-25 C.7. Since draft-ietf-quic-tls-25
* No changes * No changes
C.7. Since draft-ietf-quic-tls-24 C.8. 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.8. Since draft-ietf-quic-tls-23 C.9. 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.9. Since draft-ietf-quic-tls-22 C.10. 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.10. Since draft-ietf-quic-tls-21 C.11. Since draft-ietf-quic-tls-21
* No changes * No changes
C.11. Since draft-ietf-quic-tls-20 C.12. 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.12. Since draft-ietf-quic-tls-18 C.13. 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.13. Since draft-ietf-quic-tls-17 C.14. 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.14. Since draft-ietf-quic-tls-14 C.15. 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 60, line 35 skipping to change at page 60, line 49
* 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.15. Since draft-ietf-quic-tls-13 C.16. Since draft-ietf-quic-tls-13
* Updated to TLS 1.3 final (#1660) * Updated to TLS 1.3 final (#1660)
C.16. Since draft-ietf-quic-tls-12 C.17. 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 4 skipping to change at page 61, line 18
#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.17. Since draft-ietf-quic-tls-11 C.18. Since draft-ietf-quic-tls-11
* Encrypted packet numbers. * Encrypted packet numbers.
C.18. Since draft-ietf-quic-tls-10 C.19. Since draft-ietf-quic-tls-10
* No significant changes. * No significant changes.
C.19. Since draft-ietf-quic-tls-09 C.20. 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.20. Since draft-ietf-quic-tls-08 C.21. 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.21. Since draft-ietf-quic-tls-07 C.22. 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.22. Since draft-ietf-quic-tls-05 C.23. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
C.23. Since draft-ietf-quic-tls-04 C.24. 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.24. Since draft-ietf-quic-tls-03 C.25. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
C.25. Since draft-ietf-quic-tls-02 C.26. Since draft-ietf-quic-tls-02
* Updates to match changes in transport draft * Updates to match changes in transport draft
C.26. Since draft-ietf-quic-tls-01 C.27. 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 62, line 30 skipping to change at page 62, line 42
* 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.27. Since draft-ietf-quic-tls-00 C.28. 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.28. Since draft-thomson-quic-tls-01 C.29. 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. 88 change blocks. 
156 lines changed or deleted 194 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/