< draft-ietf-quic-tls-32.txt   draft-ietf-quic-tls-33.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: 23 April 2021 sn3rd Expires: 16 June 2021 sn3rd
20 October 2020 13 December 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-32 draft-ietf-quic-tls-33
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 23 April 2021. This Internet-Draft will expire on 16 June 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 3, line 6 skipping to change at page 3, line 6
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 25 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 25
5.4.1. Header Protection Application . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . 30 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 . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . 35
6.2. Responding to a Key Update . . . . . . . . . . . . . . . 35 6.2. Responding to a Key Update . . . . . . . . . . . . . . . 36
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 . . . . . . . . . . . . . . . . . . . 43 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
9.7. Randomness . . . . . . . . . . . . . . . . . . . . . . . 46
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 46 11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 48 11.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 49 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 50
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 50 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 51
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 52 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 53
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 53 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 53 A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 54
Appendix B. AEAD Algorithm Analysis . . . . . . . . . . . . . . 55 Appendix B. AEAD Algorithm Analysis . . . . . . . . . . . . . . 56
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 . . . . . . . . . . . . . . . . . . . . . . . . . 57
B.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 56 B.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 57
B.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 56 B.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 57
B.2. Analysis of AEAD_AES_128_CCM Usage Limits . . . . . . . . 57 B.2. Analysis of AEAD_AES_128_CCM Usage Limits . . . . . . . . 58
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 58 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 59
C.1. Since draft-ietf-quic-tls-31 . . . . . . . . . . . . . . 58 C.1. Since draft-ietf-quic-tls-32 . . . . . . . . . . . . . . 59
C.2. Since draft-ietf-quic-tls-30 . . . . . . . . . . . . . . 58 C.2. Since draft-ietf-quic-tls-31 . . . . . . . . . . . . . . 59
C.3. Since draft-ietf-quic-tls-29 . . . . . . . . . . . . . . 58 C.3. Since draft-ietf-quic-tls-30 . . . . . . . . . . . . . . 59
C.4. Since draft-ietf-quic-tls-28 . . . . . . . . . . . . . . 58 C.4. Since draft-ietf-quic-tls-29 . . . . . . . . . . . . . . 59
C.5. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 59 C.5. Since draft-ietf-quic-tls-28 . . . . . . . . . . . . . . 60
C.6. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 59 C.6. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 60
C.7. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 59 C.7. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 60
C.8. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 59 C.8. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 60
C.9. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 59 C.9. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 60
C.10. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 59 C.10. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 60
C.11. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 59 C.11. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 61
C.12. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 60 C.12. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 61
C.13. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 60 C.13. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 61
C.14. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 60 C.14. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 61
C.15. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 60 C.15. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 61
C.16. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 60 C.16. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 61
C.17. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 61 C.17. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 62
C.18. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 61 C.18. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 62
C.19. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 61 C.19. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 62
C.20. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 61 C.20. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 62
C.21. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 61 C.21. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 62
C.22. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 61 C.22. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 62
C.23. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 61 C.23. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 62
C.24. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 62 C.24. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 63
C.25. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 62 C.25. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 63
C.26. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 62 C.26. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 63
C.27. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 62 C.27. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 63
C.28. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 62 C.28. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 63
C.29. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 63 C.29. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 63
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.30. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
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
connections can be established and secured within a single round connections can be established and secured within a single round
trip; on subsequent connections between the same client and server, trip; on subsequent connections between the same client and server,
skipping to change at page 6, line 20 skipping to change at page 6, line 20
* 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 0-RTT is not suitable for carrying instructions that might so 0-RTT is not suitable for carrying instructions that might
initiate any non-idempotent action. initiate any action that could cause unwanted effects if replayed.
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 18, line 37 skipping to change at page 18, line 37
Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT
packets. packets.
A client that attempts 0-RTT might also provide an address validation A client that attempts 0-RTT might also provide an address validation
token if the server has sent a NEW_TOKEN frame; see Section 8.1 of token if the server has sent a NEW_TOKEN frame; see Section 8.1 of
[QUIC-TRANSPORT]. [QUIC-TRANSPORT].
4.6.2. Accepting and Rejecting 0-RTT 4.6.2. Accepting and Rejecting 0-RTT
A server accepts 0-RTT by sending an early_data extension in the A server accepts 0-RTT by sending an early_data extension in the
EncryptedExtensions (see Section 4.2.10 of [TLS13]). The server then EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then
processes and acknowledges the 0-RTT packets that it receives. processes and acknowledges the 0-RTT packets that it receives.
A server rejects 0-RTT by sending the EncryptedExtensions without an A server rejects 0-RTT by sending the EncryptedExtensions without an
early_data extension. A server will always reject 0-RTT if it sends early_data extension. A server will always reject 0-RTT if it sends
a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT
process any 0-RTT packets, even if it could. When 0-RTT was process any 0-RTT packets, even if it could. When 0-RTT was
rejected, a client SHOULD treat receipt of an acknowledgement for a rejected, a client SHOULD treat receipt of an acknowledgement for a
0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it 0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition. is able to detect the condition.
skipping to change at page 23, line 15 skipping to change at page 23, line 15
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.
5.2. Initial Secrets 5.2. Initial Secrets
Initial packets apply the packet protection process, but use a secret Initial packets apply the packet protection process, but use a secret
derived from the Destination Connection ID field from the client's derived from the Destination Connection ID field from the client's
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 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a 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
from TLS [TLS13] to produce a 32-byte secret. Packets constructed by from TLS [TLS13] to produce a 32-byte secret. Packets constructed by
the server use the same process with the label "server in". The hash the server use the same process with the label "server in". The hash
function for HKDF when deriving initial secrets and keys is SHA-256 function for HKDF when deriving initial secrets and keys is SHA-256
[SHA]. [SHA].
This process in pseudocode is: This process in pseudocode is:
initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899 initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
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)
server_initial_secret = HKDF-Expand-Label(initial_secret, server_initial_secret = HKDF-Expand-Label(initial_secret,
"server in", "", "server in", "",
Hash.length) Hash.length)
skipping to change at page 26, line 42 skipping to change at page 26, line 42
# 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 Specific header protection functions are defined based on the
selected cipher suite; see Section 5.4.3 and Section 5.4.4. 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 (1-RTT). Figure 7 shows the fields in each header that
covered by header protection and the portion of the protected packet are covered by header protection and the portion of the protected
payload that is sampled. packet 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
Packet Number Length (2), # Protected Packet Number Length (2), # Protected
Version (32), Version (32),
DCID Len (8), DCID Len (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
skipping to change at page 27, line 25 skipping to change at page 27, line 25
Source Connection ID (0..160), Source Connection ID (0..160),
Token Length (i), Token Length (i),
Token (..), Token (..),
Length (i), Length (i),
Packet Number (8..32), # Protected Packet Number (8..32), # Protected
Protected Payload (0..24), # Skipped Part Protected Payload (0..24), # Skipped Part
Protected Payload (128), # Sampled Part Protected Payload (128), # Sampled Part
Protected Payload (..) # Remainder Protected Payload (..) # Remainder
} }
Short Header Packet { 1-RTT Packet {
Header Form (1) = 0, Header Form (1) = 0,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Spin Bit (1), Spin Bit (1),
Reserved Bits (2), # Protected Reserved Bits (2), # Protected
Key Phase (1), # Protected Key Phase (1), # Protected
Packet Number Length (2), # Protected Packet Number Length (2), # Protected
Destination Connection ID (0..160), Destination Connection ID (0..160),
Packet Number (8..32), # Protected Packet Number (8..32), # Protected
Protected Payload (0..24), # Skipped Part Protected Payload (0..24), # Skipped Part
Protected Payload (128), # Sampled Part Protected Payload (128), # Sampled Part
skipping to change at page 28, line 25 skipping to change at page 28, line 25
padded so that the combined lengths of the encoded packet number and padded so that the combined lengths of the encoded packet number and
protected payload is at least 4 bytes longer than the sample required protected payload is at least 4 bytes longer than the sample required
for header protection. The cipher suites defined in [TLS13] - other for header protection. The cipher suites defined in [TLS13] - other
than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme
is not defined in this document - have 16-byte expansions and 16-byte is not defined in this document - have 16-byte expansions and 16-byte
header protection samples. This results in needing at least 3 bytes header protection samples. This results in needing at least 3 bytes
of frames in the unprotected payload if the packet number is encoded of frames in the unprotected payload if the packet number is encoded
on a single byte, or 2 bytes of frames for a 2-byte packet number on a single byte, or 2 bytes of frames for a 2-byte packet number
encoding. encoding.
The sampled ciphertext for a packet with a short header can be The sampled ciphertext can be determined by the following pseudocode:
determined by the following pseudocode:
sample_offset = 1 + len(connection_id) + 4 # pn_offset is the start of the Packet Number field.
sample_offset = pn_offset + 4
sample = packet[sample_offset..sample_offset+sample_length] sample = packet[sample_offset..sample_offset+sample_length]
For example, for a packet with a short header, an 8-byte connection where the packet number offset of a short header packet can be
ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to calculated as:
28 inclusive (using zero-based indexing).
A packet with a long header is sampled in the same way, noting that pn_offset = 1 + len(connection_id)
multiple QUIC packets might be included in the same UDP datagram and
that each one is handled separately.
sample_offset = 7 + len(destination_connection_id) + and the packet number offset of a long header packet can be
len(source_connection_id) + calculated as:
len(payload_length) + 4
pn_offset = 7 + len(destination_connection_id) +
len(source_connection_id) +
len(payload_length)
if packet_type == Initial: if packet_type == Initial:
sample_offset += len(token_length) + pn_offset += len(token_length) +
len(token) len(token)
sample = packet[sample_offset..sample_offset+sample_length] For example, for a packet with a short header, an 8-byte connection
ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to
28 inclusive (using zero-based indexing).
Multiple QUIC packets might be included in the same UDP datagram.
Each packet is handled separately.
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
skipping to change at page 30, line 26 skipping to change at page 30, line 26
existence of a protocol error in a peer or an attack. The truncated existence of a protocol error in a peer or an attack. The truncated
packet number encoding used in QUIC can cause packet numbers to be packet number encoding used in QUIC can cause packet numbers to be
decoded incorrectly if they are delayed significantly. decoded incorrectly if they are delayed significantly.
5.6. Use of 0-RTT Keys 5.6. Use of 0-RTT Keys
If 0-RTT keys are available (see Section 4.6.1), the lack of replay If 0-RTT keys are available (see Section 4.6.1), the lack of replay
protection means that restrictions on their use are necessary to protection means that restrictions on their use are necessary to
avoid replay attacks on the protocol. avoid replay attacks on the protocol.
A client MUST only use 0-RTT keys to protect data that is idempotent. Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM,
and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT
as they carry application data. Application data that is received in
0-RTT could cause an application at the server to process the data
multiple times rather than just once. Additional actions taken by a
server as a result of processing replayed application data could have
unwanted consequences. A client therefore MUST NOT use 0-RTT for
application data unless specifically requested by the application
that is in use.
An application protocol that uses QUIC MUST include a profile that
defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to
carry QUIC frames that do not carry application data. For example, a
profile for HTTP is described in [HTTP-REPLAY] and used for HTTP/3;
see Section 10.9 of [QUIC-HTTP].
Though replaying packets might result in additional connection
attempts, the effect of processing replayed frames that do not carry
application data is limited to changing the state of the affected
connection. A TLS handshake cannot be successfully completed using
replayed packets.
A client MAY wish to apply additional restrictions on what data it A client MAY wish to apply additional restrictions on what data it
sends prior to the completion of the TLS handshake. A client sends prior to the completion of the TLS handshake.
otherwise treats 0-RTT keys as equivalent to 1-RTT keys, except that
it MUST NOT send ACKs with 0-RTT keys. A client otherwise treats 0-RTT keys as equivalent to 1-RTT keys,
except that it cannot send certain frames with 0-RTT keys; see
Section 12.5 of [QUIC-TRANSPORT].
A client that receives an indication that its 0-RTT data has been A client that receives an indication that its 0-RTT data has been
accepted by a server can send 0-RTT data until it receives all of the accepted by a server can send 0-RTT data until it receives all of the
server's handshake messages. A client SHOULD stop sending 0-RTT data server's handshake messages. A client SHOULD stop sending 0-RTT data
if it receives an indication that 0-RTT data has been rejected. if it receives an indication that 0-RTT data has been rejected.
A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT
keys to protect acknowledgements of 0-RTT packets. A client MUST NOT keys to protect acknowledgements of 0-RTT packets. A client MUST NOT
attempt to decrypt 0-RTT packets it receives and instead MUST discard attempt to decrypt 0-RTT packets it receives and instead MUST discard
them. them.
skipping to change at page 32, line 26 skipping to change at page 32, line 48
Retry packets (see the Retry Packet section of [QUIC-TRANSPORT]) Retry packets (see the Retry Packet section of [QUIC-TRANSPORT])
carry a Retry Integrity Tag that provides two properties: it allows carry a Retry Integrity Tag that provides two properties: it allows
discarding packets that have accidentally been corrupted by the discarding packets that have accidentally been corrupted by the
network, and it diminishes off-path attackers' ability to send valid network, and it diminishes off-path attackers' ability to send valid
Retry packets. Retry packets.
The Retry Integrity Tag is a 128-bit field that is computed as the The Retry Integrity Tag is a 128-bit field that is computed as the
output of AEAD_AES_128_GCM ([AEAD]) used with the following inputs: output of AEAD_AES_128_GCM ([AEAD]) used with the following inputs:
* The secret key, K, is 128 bits equal to * The secret key, K, is 128 bits equal to
0xccce187ed09a09d05728155a6cb96be1. 0xbe0c690b9f66575a1d766b54e368c84e.
* The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c. * The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb.
* The plaintext, P, is empty. * The plaintext, P, is empty.
* The associated data, A, is the contents of the Retry Pseudo- * The associated data, A, is the contents of the Retry Pseudo-
Packet, as illustrated in Figure 8: Packet, as illustrated in Figure 8:
The secret key and the nonce are values derived by calling HKDF- The secret key and the nonce are values derived by calling HKDF-
Expand-Label using Expand-Label using
0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c as 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as
the secret, with labels being "quic key" and "quic iv" (Section 5.1). the secret, with labels being "quic key" and "quic iv" (Section 5.1).
Retry Pseudo-Packet { Retry Pseudo-Packet {
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),
skipping to change at page 34, line 5 skipping to change at page 34, line 15
The Key Phase bit indicates which packet protection keys are used to The Key Phase bit indicates which packet protection keys are used to
protect the packet. The Key Phase bit is initially set to 0 for the protect the packet. The Key Phase bit is initially set to 0 for the
first set of 1-RTT packets and toggled to signal each subsequent key first set of 1-RTT packets and toggled to signal each subsequent key
update. update.
The Key Phase bit allows a recipient to detect a change in keying The Key Phase bit allows a recipient to detect a change in keying
material without needing to receive the first packet that triggered material without needing to receive the first packet that triggered
the change. An endpoint that notices a changed Key Phase bit updates the change. An endpoint that notices a changed Key Phase bit updates
keys and decrypts the packet that contains the changed value. keys and decrypts the packet that contains the changed value.
This mechanism replaces the TLS KeyUpdate message. Endpoints MUST This mechanism replaces the key update mechanism of TLS, which relies
NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints
of a TLS KeyUpdate message as a connection error of type 0x10a, MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the
equivalent to a fatal TLS alert of unexpected_message (see receipt of a TLS KeyUpdate message in a 1-RTT packet as a connection
Section 4.8). error of type 0x10a, equivalent to a fatal TLS alert of
unexpected_message; see Section 4.8.
Figure 9 shows a key update process, where the initial set of keys Figure 9 shows a key update process, where the initial set of keys
used (identified with @M) are replaced by updated keys (identified used (identified with @M) are replaced by updated keys (identified
with @N). The value of the Key Phase bit is indicated in brackets with @N). The value of the Key Phase bit is indicated in brackets
[]. [].
Initiating Peer Responding Peer Initiating Peer Responding Peer
@M [0] QUIC Packets @M [0] QUIC Packets
skipping to change at page 40, line 30 skipping to change at page 40, line 32
The KEY_UPDATE_ERROR error code (0xe) is used to signal errors The KEY_UPDATE_ERROR error code (0xe) is used to signal errors
related to key updates. related to key updates.
7. Security of Initial Messages 7. Security of Initial Messages
Initial packets are not protected with a secret key, so they are Initial packets are not protected with a secret key, so they are
subject to potential tampering by an attacker. QUIC provides subject to potential tampering by an attacker. QUIC provides
protection against attackers that cannot read packets, but does not protection against attackers that cannot read packets, but does not
attempt to provide additional protection against attacks where the attempt to provide additional protection against attacks where the
attacker can observe and inject packets. Some forms of tampering - attacker can observe and inject packets. Some forms of tampering --
such as modifying the TLS messages themselves - are detectable, but such as modifying the TLS messages themselves -- are detectable, but
some - such as modifying ACKs - are not. some -- such as modifying ACKs -- are not.
For example, an attacker could inject a packet containing an ACK For example, an attacker could inject a packet containing an ACK
frame that makes it appear that a packet had not been received or to frame that makes it appear that a packet had not been received or to
create a false impression of the state of the connection (e.g., by create a false impression of the state of the connection (e.g., by
modifying the ACK Delay). Note that such a packet could cause a modifying the ACK Delay). Note that such a packet could cause a
legitimate packet to be dropped as a duplicate. Implementations legitimate packet to be dropped as a duplicate. Implementations
SHOULD use caution in relying on any data that is contained in SHOULD use caution in relying on any data that is contained in
Initial packets that is not otherwise authenticated. Initial packets that is not otherwise authenticated.
It is also possible for the attacker to tamper with data that is It is also possible for the attacker to tamper with data that is
skipping to change at page 41, line 42 skipping to change at page 41, line 42
8.2. QUIC Transport Parameters Extension 8.2. QUIC Transport Parameters Extension
QUIC transport parameters are carried in a TLS extension. Different QUIC transport parameters are carried in a TLS extension. Different
versions of QUIC might define a different method for negotiating versions of QUIC might define a different method for negotiating
transport configuration. transport configuration.
Including transport parameters in the TLS handshake provides Including transport parameters in the TLS handshake provides
integrity protection for these values. integrity protection for these values.
enum { enum {
quic_transport_parameters(0xffa5), (65535) quic_transport_parameters(0x39), (65535)
} ExtensionType; } ExtensionType;
The extension_data field of the quic_transport_parameters extension The extension_data field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in contains a value that is defined by the version of QUIC that is in
use. use.
The quic_transport_parameters extension is carried in the ClientHello The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake. Endpoints and the EncryptedExtensions messages during the handshake. Endpoints
MUST send the quic_transport_parameters extension; endpoints that MUST send the quic_transport_parameters extension; endpoints that
receive ClientHello or EncryptedExtensions messages without the receive ClientHello or EncryptedExtensions messages without the
skipping to change at page 46, line 40 skipping to change at page 46, line 40
To preserve this separation, a new version of QUIC SHOULD define new To preserve this separation, a new version of QUIC SHOULD define new
labels for key derivation for packet protection key and IV, plus the labels for key derivation for packet protection key and IV, plus the
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.
9.7. Randomness
QUIC depends on endpoints being able to generate secure random
numbers, both directly for protocol values such as the connection ID,
and transitively via TLS. See [RFC4086] for guidance on secure
random number generation.
10. IANA Considerations 10. IANA Considerations
This document registers the quic_transport_parameters extension found IANA has registered a codepoint of 57 (or 0x39) for the
in Section 8.2 in the TLS ExtensionType Values Registry quic_transport_parameters extension (defined in Section 8.2) in the
[TLS-REGISTRIES]. TLS ExtensionType Values Registry [TLS-REGISTRIES].
The Recommended column is to be marked Yes. The TLS 1.3 Column is to The Recommended column for this extension is marked Yes. The TLS 1.3
include CH and EE. Column includes 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)", National Institute [AES] "Advanced encryption standard (AES)", National Institute
skipping to change at page 47, line 31 skipping to change at page 47, line 38
<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-32, 20 October 2020, draft-ietf-quic-recovery-33, 13 December 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-32>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-33>.
[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-32, 20 October Internet-Draft, draft-ietf-quic-transport-33, 13 December
2020, <https://tools.ietf.org/html/draft-ietf-quic- 2020, <https://tools.ietf.org/html/draft-ietf-quic-
transport-32>. transport-33>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHA] Dang, Q., "Secure Hash Standard", National Institute of [SHA] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology report, Standards and Technology report,
DOI 10.6028/nist.fips.180-4, 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]
skipping to change at page 48, line 42 skipping to change at page 48, line 51
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-
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", Proceedings of the 2018 user Security of GCM, Revisited: Tight Bounds for Nonce
ACM SIGSAC Conference on Computer and Randomization", Proceedings of the 2018 ACM SIGSAC
Communications Security, DOI 10.1145/3243734.3243816, Conference on Computer and Communications Security,
January 2018, <https://doi.org/10.1145/3243734.3243816>. DOI 10.1145/3243734.3243816, January 2018,
<https://doi.org/10.1145/3243734.3243816>.
[HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>.
[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, 6 Cryptography, Second Edition", ISBN 978-1466570269, 6
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-32, 20 October 2020, quic-http-32, 13 December 2020,
<https://tools.ietf.org/html/draft-ietf-quic-http-32>. <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,
skipping to change at page 49, line 46 skipping to change at page 50, line 16
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.
A.1. Keys A.1. Keys
The labels generated by the HKDF-Expand-Label function are: The labels generated during the execution of the HKDF-Expand-Label
function and given to the HKDF-Expand function in order to produce
its output are:
client in: 00200f746c73313320636c69656e7420696e00 client in: 00200f746c73313320636c69656e7420696e00
server in: 00200f746c7331332073657276657220696e00 server in: 00200f746c7331332073657276657220696e00
quic key: 00100e746c7331332071756963206b657900 quic key: 00100e746c7331332071756963206b657900
quic iv: 000c0d746c733133207175696320697600 quic iv: 000c0d746c733133207175696320697600
quic hp: 00100d746c733133207175696320687000 quic hp: 00100d746c733133207175696320687000
The initial secret is common: The initial secret is common:
initial_secret = HKDF-Extract(initial_salt, cid) initial_secret = HKDF-Extract(initial_salt, cid)
= 1e7e7764529715b1e0ddc8e9753c6157 = 7db5df06e7a69e432496adedb0085192
6769605187793ed366f8bbf8c9e986eb 3595221596ae2ae9fb8115c1e9ed0a44
The secrets for protecting client packets are: The secrets for protecting client packets are:
client_initial_secret client_initial_secret
= HKDF-Expand-Label(initial_secret, "client in", _, 32) = HKDF-Expand-Label(initial_secret, "client in", _, 32)
= 0088119288f1d866733ceeed15ff9d50 = c00cf151ca5be075ed0ebfb5c80323c4
902cf82952eee27e9d4d4918ea371d87 2d6b7db67881289af4008f1f6c357aea
key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16) key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
= 175257a31eb09dea9366d8bb79ad80ba = 1f369613dd76d5467730efcbe3b1a22d
iv = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12) iv = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
= 6b26114b9cba2b63a9e8dd4f = fa044b2f42a3fd3b46fb255c
hp = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16) hp = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
= 9ddd12c994c0698b89374a9c077a3077 = 9f50449e04a0e810283a1e9933adedd2
The secrets for protecting server packets are: The secrets for protecting server packets are:
server_initial_secret server_initial_secret
= HKDF-Expand-Label(initial_secret, "server in", _, 32) = HKDF-Expand-Label(initial_secret, "server in", _, 32)
= 006f881359244dd9ad1acf85f595bad6 = 3c199828fd139efd216c155ad844cc81
7c13f9f5586f5e64e1acae1d9ea8f616 fb82fa8d7446fa7d78be803acdda951b
key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16) key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
= 149d0b1662ab871fbe63c49b5e655a5d = cf3a5331653c364c88f0f379b6067e37
iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12) iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
= bab2b12a4c76016ace47856d = 0ac1493ca1905853b0bba03e
hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16) hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
= c0c499a65a60024a18a250974ea01dfa = c206b8d9b9f0f37644430b490eeaa314
A.2. Client Initial A.2. Client Initial
The client sends an Initial packet. The unprotected payload of this The client sends an Initial packet. The unprotected payload of this
packet contains the following CRYPTO frame, plus enough PADDING packet contains the following CRYPTO frame, plus enough PADDING
frames to make a 1162 byte payload: frames to make a 1162 byte payload:
060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868 060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578 04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
616d706c652e636f6dff01000100000a 00080006001d00170018001000070005 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400 baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
0d0010000e0403050306030203080408 050806002d00020101001c00024001ff 0d0010000e0403050306030203080408 050806002d00020101001c0002400100
a500320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 3900320408ffffffffffffffff050480 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:
c3ff000020088394c8f03e5157080000449e00000002 c300000001088394c8f03e5157080000449e00000002
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 = d1b1c98dd7689fb8ec11d242b123dc9b
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 1e9cdb9909 = 437b9aec36
header[0] ^= mask[0] & 0x0f header[0] ^= mask[0] & 0x0f
= cd = c0
header[18..21] ^= mask[1..4] header[18..21] ^= mask[1..4]
= 9cdb990b = 7b9aec34
header = cdff000020088394c8f03e5157080000449e9cdb990b header = c000000001088394c8f03e5157080000449e7b9aec34
The resulting protected packet is: The resulting protected packet is:
cdff000020088394c8f03e5157080000 449e9cdb990bfb66bc6a93032b50dd89 c000000001088394c8f03e5157080000 449e7b9aec34d1b1c98dd7689fb8ec11
73972d149421874d3849e3708d71354e a33bcdc356f3ea6e2a1a1bd7c3d14003 d242b123dc9bd8bab936b47d92ec356c 0bab7df5976d27cd449f63300099f399
8d3e784d04c30a2cdb40c32523aba2da fe1c1bf3d27a6be38fe38ae033fbb071 1c260ec4c60d17b31f8429157bb35a12 82a643a8d2262cad67500cadb8e7378c
3c1c73661bb6639795b42b97f77068ea d51f11fbf9489af2501d09481e6c64d4 8eb7539ec4d4905fed1bee1fc8aafba1 7c750e2c7ace01e6005f80fcb7df6212
b8551cd3cea70d830ce2aeeec789ef55 1a7fbe36b3f7e1549a9f8d8e153b3fac 30c83711b39343fa028cea7f7fb5ff89 eac2308249a02252155e2347b63d58c5
3fb7b7812c9ed7c20b4be190ebd89956 26e7f0fc887925ec6f0606c5d36aa81b 457afd84d05dfffdb20392844ae81215 4682e9cf012f9021a6f0be17ddd0c208
ebb7aacdc4a31bb5f23d55faef5c5190 5783384f375a43235b5c742c78ab1bae 4dce25ff9b06cde535d0f920a2db1bf3 62c23e596d11a4f5a6cf3948838a3aec
0a188b75efbde6b3774ed61282f9670a 9dea19e1566103ce675ab4e21081fb58 4e15daf8500a6ef69ec4e3feb6b1d98e 610ac8b7ec3faf6ad760b7bad1db4ba3
60340a1e88e4f10e39eae25cd685b109 29636d4f02e7fad2a5a458249f5c0298 485e8a94dc250ae3fdb41ed15fb6a8e5 eba0fc3dd60bc8e30c5c4287e53805db
a6d53acbe41a7fc83fa7cc01973f7a74 d1237a51974e097636b6203997f921d0 059ae0648db2f64264ed5e39be2e20d8 2df566da8dd5998ccabdae053060ae6c
7bc1940a6f2d0de9f5a11432946159ed 6cc21df65c4ddd1115f86427259a196c 7b4378e846d29f37ed7b4ea9ec5d82e7 961b7f25a9323851f681d582363aa5f8
7148b25b6478b0dc7766e1c4d1b1f515 9f90eabc61636226244642ee148b464c 9937f5a67258bf63ad6f1a0b1d96dbd4 faddfcefc5266ba6611722395c906556
9e619ee50a5e3ddc836227cad938987c 4ea3c1fa7c75bbf88d89e9ada642b2b8 be52afe3f565636ad1b17d508b73d874 3eeb524be22b3dcbc2c7468d54119c74
8fe8107b7ea375b1b64889a4e9e5c38a 1c896ce275a5658d250e2d76e1ed3a34 68449a13d8e3b95811a198f3491de3e7 fe942b330407abf82a4ed7c1b311663a
ce7e3a3f383d0c996d0bed106c2899ca 6fc263ef0455e74bb6ac1640ea7bfedc c69890f4157015853d91e923037c227a 33cdd5ec281ca3f79c44546b9d90ca00
59f03fee0e1725ea150ff4d69a7660c5 542119c71de270ae7c3ecfd1af2c4ce5 f064c99e3dd97911d39fe9c5d0b23a22 9a234cb36186c4819e8b9c5927726632
51986949cc34a66b3e216bfe18b347e6 c05fd050f85912db303a8f054ec23e38 291d6a418211cc2962e20fe47feb3edf 330f2c603a9d48c0fcb5699dbfe58964
f44d1c725ab641ae929fecc8e3cefa56 19df4231f5b4c009fa0c0bbc60bc75f7 25c5bac4aee82e57a85aaf4e2513e4f0 5796b07ba2ee47d80506f8d2c25e50fd
6d06ef154fc8577077d9d6a1d2bd9bf0 81dc783ece60111bea7da9e5a9748069 14de71e6c418559302f939b0e1abd576 f279c4b2e0feb85c1f28ff18f58891ff
d078b2bef48de04cabe3755b197d52b3 2046949ecaa310274b4aac0d008b1948 ef132eef2fa09346aee33c28eb130ff2 8f5b766953334113211996d20011a198
c1082cdfe2083e386d4fd84c0ed0666d 3ee26c4515c4fee73433ac703b690a9f e3fc433f9f2541010ae17c1bf202580f 6047472fb36857fe843b19f5984009dd
7bf278a77486ace44c489a0c7ac8dfe4 d1a58fb3a730b993ff0f0d61b4d89557 c324044e847a4f4a0ab34f719595de37 252d6235365e9b84392b061085349d73
831eb4c752ffd39c10f6b9f46d8db278 da624fd800e4af85548a294c1518893a 203a4a13e96f5432ec0fd4a1ee65accd d5e3904df54c1da510b0ff20dcc0c77f
8778c4f6d6d73c93df200960104e062b 388ea97dcf4016bced7f62b4f062cb6c cb2c0e0eb605cb0504db87632cf3d8b4 dae6e705769d1de354270123cb11450e
04c20693d9a0e3b74ba8fe74cc012378 84f40d765ae56a51688d985cf0ceaef4 fc60ac47683d7b8d0f811365565fd98c 4c8eb936bcab8d069fc33bd801b03ade
3045ed8c3f0c33bced08537f6882613a cd3b08d665fce9dd8aa73171e2d3771a a2e1fbc5aa463d08ca19896d2bf59a07 1b851e6c239052172f296bfb5e724047
61dba2790e491d413d93d987e2745af2 9418e428be34941485c93447520ffe23 90a2181014f3b94a4e97d117b4381303 68cc39dbb2d198065ae3986547926cd2
1da2304d6a0fd5d07d08372202369661 59bef3cf904d722324dd852513df39ae 162f40a29f0c3c8745c0f50fba3852e5 66d44575c29d39a03f0cda721984b6f4
030d8173908da6364786d3c1bfcb19ea 77a63b25f1e7fc661def480c5d00d444 40591f355e12d439ff150aab7613499d bd49adabc8676eef023b15b65bfc5ca0
56269ebd84efd8e3a8b2c257eec76060 682848cbf5194bc99e49ee75e4d0d254 6948109f23f350db82123535eb8a7433 bdabcb909271a6ecbcb58b936a88cd4e
bad4bfd74970c30e44b65511d4ad0e6e c7398e08e01307eeeea14e46ccd87cf3 8f2e6ff5800175f113253d8fa9ca8885 c2f552e657dc603f252e1a8e308f76f0
6b285221254d8fc6a6765c524ded0085 dca5bd688ddf722e2c0faf9d0fb2ce7a be79e2fb8f5d5fbbe2e30ecadd220723 c8c0aea8078cdfcb3868263ff8f09400
0c3f2cee19ca0ffba461ca8dc5d2c817 8b0762cf67135558494d2a96f1a139f0 54da48781893a7e49ad5aff4af300cd8 04a6b6279ab3ff3afb64491c85194aab
edb42d2af89a9c9122b07acbc29e5e72 2df8615c343702491098478a389c9872 760d58a606654f9f4400e8b38591356f bf6425aca26dc85244259ff2b19c41b9
a10b0c9875125e257c7bfdf27eef4060 bd3d00f4c14fd3e3496c38d3c5d1a566 f96f3ca9ec1dde434da7d2d392b905dd f3d1f9af93d1af5950bd493f5aa731b4
8c39350effbc2d16ca17be4ce29f02ed 969504dda2a8c6b9ff919e693ee79e09 056df31bd267b6b90a079831aaf579be 0a39013137aac6d404f518cfd4684064
089316e7d1d89ec099db3b2b268725d8 88536a4b8bf9aee8fb43e82a4d919d48 7e78bfe706ca4cf5e9c5453e9f7cfd2b 8b4c8d169a44e55c88d4a9a7f9474241
b5a464ca5b62df3be35ee0d0a2ec68f3 e221af44860018ab0856972e194cd934
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:
c1ff0000200008f067a5502a4262b50040750001 c1000000010008f067a5502a4262b50040750001
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 = 823a5d24534d906ce4c76782a2167e34 sample = 2cd0991cd25b0aac406a5816b6394100
mask = abaaf34fdc mask = 2ec0d8356a
header = c7ff0000200008f067a5502a4262b5004075fb12 header = cf000000010008f067a5502a4262b5004075c0d9
The final protected packet is then: The final protected packet is then:
c7ff0000200008f067a5502a4262b500 4075fb12ff07823a5d24534d906ce4c7 cf000000010008f067a5502a4262b500 4075c0d95a482cd0991cd25b0aac406a
6782a2167e3479c0f7f6395dc2c91676 302fe6d70bb7cbeb117b4ddb7d173498 5816b6394100f37a1c69797554780bb3 8cc5a99f5ede4cf73c3ec2493a1839b3
44fd61dae200b8338e1b932976b61d91 e64a02e9e0ee72e3a6f63aba4ceeeec5 dbcba3f6ea46c5b7684df3548e7ddeb9 c3bf9c73cc3f3bded74b562bfb19fb84
be2f24f2d86027572943533846caa13e 6f163fb257473d0eda5047360fd4a47e 022f8ef4cdd93795d77d06edbb7aaf2f 58891850abbdca3d20398c276456cbc4
fd8142fafc0f76 2158407dd074ee
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:
ffff0000200008f067a5502a4262b574 6f6b656e59756519dd6cc85bd90e33a9 ff000000010008f067a5502a4262b574 6f6b656e04a265ba2eff4d829058fb3f
34d2ff85 0f2496ba
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 58, line 28 skipping to change at page 59, line 28
packets. Endpoints that do not restrict packet size have a limit of packets. Endpoints that do not restrict packet size have a limit of
2^21.5. 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-31 C.1. Since draft-ietf-quic-tls-32
* Added final values for Initial key derivation, Retry
authentication, and TLS extension type for the QUIC Transport
Parameters extension (#4431) (#4431)
* Corrected rules for handling of 0-RTT (#4393, #4394)
C.2. Since draft-ietf-quic-tls-31
* Packet protection limits are based on maximum-sized packets; * Packet protection limits are based on maximum-sized packets;
improved analysis (#3701, #4175) improved analysis (#3701, #4175)
C.2. Since draft-ietf-quic-tls-30 C.3. 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.3. Since draft-ietf-quic-tls-29 C.4. 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.4. Since draft-ietf-quic-tls-28 C.5. 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.5. Since draft-ietf-quic-tls-27 C.6. 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.6. Since draft-ietf-quic-tls-26 C.7. Since draft-ietf-quic-tls-26
* No changes * No changes
C.7. Since draft-ietf-quic-tls-25 C.8. Since draft-ietf-quic-tls-25
* No changes * No changes
C.8. Since draft-ietf-quic-tls-24 C.9. 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.9. Since draft-ietf-quic-tls-23 C.10. 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.10. Since draft-ietf-quic-tls-22 C.11. 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.11. Since draft-ietf-quic-tls-21 C.12. Since draft-ietf-quic-tls-21
* No changes * No changes
C.12. Since draft-ietf-quic-tls-20 C.13. 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.13. Since draft-ietf-quic-tls-18 C.14. 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.14. Since draft-ietf-quic-tls-17 C.15. 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.15. Since draft-ietf-quic-tls-14 C.16. 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 49 skipping to change at page 62, line 8
* 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.16. Since draft-ietf-quic-tls-13 C.17. Since draft-ietf-quic-tls-13
* Updated to TLS 1.3 final (#1660) * Updated to TLS 1.3 final (#1660)
C.17. Since draft-ietf-quic-tls-12 C.18. 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
- 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.18. Since draft-ietf-quic-tls-11 C.19. Since draft-ietf-quic-tls-11
* Encrypted packet numbers. * Encrypted packet numbers.
C.19. Since draft-ietf-quic-tls-10 C.20. Since draft-ietf-quic-tls-10
* No significant changes. * No significant changes.
C.20. Since draft-ietf-quic-tls-09 C.21. 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.21. Since draft-ietf-quic-tls-08 C.22. 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.22. Since draft-ietf-quic-tls-07 C.23. 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.23. Since draft-ietf-quic-tls-05 C.24. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
C.24. Since draft-ietf-quic-tls-04 C.25. 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.25. Since draft-ietf-quic-tls-03 C.26. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
C.26. Since draft-ietf-quic-tls-02 C.27. Since draft-ietf-quic-tls-02
* Updates to match changes in transport draft * Updates to match changes in transport draft
C.27. Since draft-ietf-quic-tls-01 C.28. 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 42 skipping to change at page 63, line 48
* 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.28. Since draft-ietf-quic-tls-00 C.29. 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.29. Since draft-thomson-quic-tls-01 C.30. 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. 90 change blocks. 
205 lines changed or deleted 263 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/