draft-ietf-quic-tls-22.txt   draft-ietf-quic-tls-23.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: January 10, 2020 sn3rd Expires: March 15, 2020 sn3rd
July 09, 2019 September 12, 2019
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-22 draft-ietf-quic-tls-23
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 January 10, 2020. This Internet-Draft will expire on March 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8 4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8
4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10 4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10
4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10 4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10
4.1.3. Sending and Receiving Handshake Messages . . . . . . 10 4.1.3. Sending and Receiving Handshake Messages . . . . . . 10
4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12 4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12
4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13 4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13
4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 14 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 14
4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 14 4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15
4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15 4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15
4.6. Rejecting 0-RTT . . . . . . . . . . . . . . . . . . . . . 15 4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16
4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 15 4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 16
4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 16 4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 16 4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 17
4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 17 4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 17
4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 17 4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 18
4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 17 4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 18
5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 18 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 18 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 18
5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 18 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 19
5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 21 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 21
5.4.1. Header Protection Application . . . . . . . . . . . . 21 5.4.1. Header Protection Application . . . . . . . . . . . . 22
5.4.2. Header Protection Sample . . . . . . . . . . . . . . 23 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 23
5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 24 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 24
5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 24 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 25
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 24 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 25
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 25 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 25
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 26
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security of Initial Messages . . . . . . . . . . . . . . . . 28 7. Security of Initial Messages . . . . . . . . . . . . . . . . 29
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 29 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 29 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 30
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 29 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 30
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 30 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 31 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 31
9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 32 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 32
9.3. Peer Denial of Service . . . . . . . . . . . . . . . . . 32 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 33
9.4. Header Protection Analysis . . . . . . . . . . . . . . . 32 9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 34
9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 36
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Sample Initial Packet Protection . . . . . . . . . . 36 Appendix A. Sample Initial Packet Protection . . . . . . . . . . 36
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 37 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 38
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 39 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 39
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 40
B.1. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 40 B.1. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 40
B.2. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 40 B.2. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 40
B.3. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 40 B.3. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 40
B.4. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 41 B.4. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 40
B.5. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 41 B.5. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 41
B.6. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 41 B.6. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 41
B.7. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 41 B.7. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 41
B.8. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 42 B.8. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 41
B.9. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 42 B.9. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 42
B.10. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 42 B.10. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 42
B.11. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 42 B.11. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 42
B.12. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 42 B.12. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 42
B.13. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 42 B.13. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 42
B.14. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 42 B.14. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 42
B.15. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 42 B.15. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 42
B.16. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 42 B.16. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 42
B.17. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 43 B.17. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 42
B.18. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 43 B.18. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 43
B.19. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 43 B.19. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 43
B.20. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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
skipping to change at page 8, line 25 skipping to change at page 8, line 25
+------------+ +------------+
| QUIC | | QUIC |
| Packet | | Packet |
| Protection | | Protection |
+------------+ +------------+
Figure 2: QUIC and TLS Interactions Figure 2: QUIC and TLS Interactions
Unlike TLS over TCP, QUIC applications which want to send data do not Unlike TLS over TCP, QUIC applications which want to send data do not
send it through TLS "application_data" records. Rather, they send it send it through TLS "application_data" records. Rather, they send it
as QUIC STREAM frames which are then carried in QUIC packets. as QUIC STREAM frames or other frame types which are then carried in
QUIC packets.
4. Carrying TLS Messages 4. Carrying TLS Messages
QUIC carries TLS handshake data in CRYPTO frames, each of which QUIC carries TLS handshake data in CRYPTO frames, each of which
consists of a contiguous block of handshake data identified by an consists of a contiguous block of handshake data identified by an
offset and length. Those frames are packaged into QUIC packets and offset and length. Those frames are packaged into QUIC packets and
encrypted under the current TLS encryption level. As with TLS over encrypted under the current TLS encryption level. As with TLS over
TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's
responsibility to deliver it reliably. Each chunk of data that is responsibility to deliver it reliably. Each chunk of data that is
produced by TLS is associated with the set of keys that TLS is produced by TLS is associated with the set of keys that TLS is
skipping to change at page 12, line 13 skipping to change at page 12, line 13
client. client.
When the handshake is complete, QUIC only needs to provide TLS with When the handshake is complete, QUIC only needs to provide TLS with
any data that arrives in CRYPTO streams. In the same way that is any data that arrives in CRYPTO streams. In the same way that is
done during the handshake, new data is requested from TLS after done during the handshake, new data is requested from TLS after
providing received data. providing received data.
4.1.4. Encryption Level Changes 4.1.4. Encryption Level Changes
As keys for new encryption levels become available, TLS provides QUIC As keys for new encryption levels become available, TLS provides QUIC
with those keys. Separately, as TLS starts using keys at a given with those keys. Separately, as keys at a given encryption level
encryption level, TLS indicates to QUIC that it is now reading or become available to TLS, TLS indicates to QUIC that reading or
writing with keys at that encryption level. These events are not writing keys at that encryption level are available. These events
asynchronous; they always occur immediately after TLS is provided are not asynchronous; they always occur immediately after TLS is
with new handshake bytes, or after TLS produces handshake bytes. provided with new handshake bytes, or after TLS produces handshake
bytes.
TLS provides QUIC with three items as a new encryption level becomes TLS provides QUIC with three items as a new encryption level becomes
available: available:
o A secret o A secret
o An Authenticated Encryption with Associated Data (AEAD) function o An Authenticated Encryption with Associated Data (AEAD) function
o A Key Derivation Function (KDF) o A Key Derivation Function (KDF)
skipping to change at page 13, line 8 skipping to change at page 13, line 9
higher and lower encryption levels than the current encryption level higher and lower encryption levels than the current encryption level
used by TLS. used by TLS.
In particular, server implementations need to be able to read packets In particular, server implementations need to be able to read packets
at the Handshake encryption level at the same time as the 0-RTT at the Handshake encryption level at the same time as the 0-RTT
encryption level. A client could interleave ACK frames that are encryption level. A client could interleave ACK frames that are
protected with Handshake keys with 0-RTT data and the server needs to protected with Handshake keys with 0-RTT data and the server needs to
process those acknowledgments in order to detect lost Handshake process those acknowledgments in order to detect lost Handshake
packets. packets.
QUIC also needs access to keys that might not ordinarily be available
to a TLS implementation. For instance, a client might need to
acknowledge Handshake packets before it is ready to send CRYPTO
frames at that encryption level. TLS therefore needs to provide keys
to QUIC before it might produce them for its own use.
4.1.5. TLS Interface Summary 4.1.5. TLS Interface Summary
Figure 3 summarizes the exchange between QUIC and TLS for both client Figure 3 summarizes the exchange between QUIC and TLS for both client
and server. Each arrow is tagged with the encryption level used for and server. Each arrow is tagged with the encryption level used for
that transmission. that transmission.
Client Server Client Server
Get Handshake Get Handshake
Initial -------------> Initial ------------->
Handshake Received
Install tx 0-RTT Keys Install tx 0-RTT Keys
0-RTT ---------------> 0-RTT --------------->
Handshake Received
Get Handshake Get Handshake
<------------- Initial <------------- Initial
Handshake Received
Install Handshake keys
Install rx 0-RTT keys Install rx 0-RTT keys
Install Handshake keys Install Handshake keys
Get Handshake Get Handshake
<----------- Handshake <----------- Handshake
Handshake Received
Install tx 1-RTT keys Install tx 1-RTT keys
<--------------- 1-RTT <--------------- 1-RTT
Handshake Received
Install tx Handshake keys
Handshake Received
Get Handshake Get Handshake
Handshake Complete Handshake Complete
Handshake -----------> Handshake ----------->
Install 1-RTT keys
1-RTT --------------->
Handshake Received Handshake Received
Install rx 1-RTT keys Install rx 1-RTT keys
Handshake Complete Handshake Complete
Install 1-RTT keys
1-RTT --------------->
Get Handshake Get Handshake
<--------------- 1-RTT <--------------- 1-RTT
Handshake Received Handshake Received
Figure 3: Interaction Summary between QUIC and TLS Figure 3: Interaction Summary between QUIC and TLS
Figure 3 shows the multiple packets that form a single "flight" of
messages being processed individually, to show what incoming messages
trigger different actions. New handshake messages are requested
after all incoming packets have been processed. This process might
vary depending on how QUIC implementations and the packets they
receive are structured.
4.2. TLS Version 4.2. TLS Version
This document describes how TLS 1.3 [TLS13] is used with QUIC. This document describes how TLS 1.3 [TLS13] is used with QUIC.
In practice, the TLS handshake will negotiate a version of TLS to In practice, the TLS handshake will negotiate a version of TLS to
use. This could result in a newer version of TLS than 1.3 being use. This could result in a newer version of TLS than 1.3 being
negotiated if both endpoints support that version. This is negotiated if both endpoints support that version. This is
acceptable provided that the features of TLS 1.3 that are used by acceptable provided that the features of TLS 1.3 that are used by
QUIC are supported by the newer version. QUIC are supported by the newer version.
skipping to change at page 15, line 29 skipping to change at page 15, line 42
In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket
message that contains the "early_data" extension with a message that contains the "early_data" extension with a
max_early_data_size of 0xffffffff; the amount of data which the max_early_data_size of 0xffffffff; the amount of data which the
client can send in 0-RTT is controlled by the "initial_max_data" client can send in 0-RTT is controlled by the "initial_max_data"
transport parameter supplied by the server. A client MUST treat transport parameter supplied by the server. A client MUST treat
receipt of a NewSessionTicket that contains an "early_data" extension receipt of a NewSessionTicket that contains an "early_data" extension
with any other value as a connection error of type with any other value as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
4.6. Rejecting 0-RTT A client that wishes to send 0-RTT packets uses the "early_data"
extension in the ClientHello message of a subsequent handshake (see
Section 4.2.10 of [TLS13]). It then sends the application data in
0-RTT packets.
A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This Early data within the TLS connection MUST NOT be used. As it is for
also prevents QUIC from sending 0-RTT data. A server will always other TLS application data, a server MUST treat receiving early data
reject 0-RTT if it sends a TLS HelloRetryRequest. on the TLS connection as a connection error of type
PROTOCOL_VIOLATION.
4.6. Accepting and Rejecting 0-RTT
A server accepts 0-RTT by sending an early_data extension in the
EncryptedExtensions (see Section 4.2.10 of [TLS13]). The server then
processes and acknowledges the 0-RTT packets that it receives.
A server rejects 0-RTT by sending the EncryptedExtensions without an
early_data extension. A server will always reject 0-RTT if it sends
a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT
process any 0-RTT packets, even if it could. When 0-RTT was
rejected, a client SHOULD treat receipt of an acknowledgement for a
0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.
When 0-RTT is rejected, all connection characteristics that the When 0-RTT is rejected, all connection characteristics that the
client assumed might be incorrect. This includes the choice of client assumed might be incorrect. This includes the choice of
application protocol, transport parameters, and any application application protocol, transport parameters, and any application
configuration. The client therefore MUST reset the state of all configuration. The client therefore MUST reset the state of all
streams, including application state bound to those streams. streams, including application state bound to those streams.
A client MAY attempt to send 0-RTT again if it receives a Retry or A client MAY attempt to send 0-RTT again if it receives a Retry or
Version Negotiation packet. These packets do not signify rejection Version Negotiation packet. These packets do not signify rejection
of 0-RTT. of 0-RTT.
skipping to change at page 18, line 34 skipping to change at page 19, line 18
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. Other versions of TLS
MUST provide a similar function in order to be used with QUIC. 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 IV; see Section 5.3. The header protection key uses to derive the IV; see Section 5.3. The header protection key uses
the "quic hp" label; see Section 5.4. Using these labels provides the "quic hp" label; see Section 5.4. Using these labels provides
key separation between QUIC and TLS; see Section 9.5. key separation between QUIC and TLS; see Section 9.4.
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 are protected with a secret derived from the Initial packets are protected with a secret derived from the
Destination Connection ID field from the client's first Initial Destination Connection ID field from the client's first Initial
packet of the connection. Specifically: packet of the connection. Specifically:
initial_salt = 0x7fbcdb0e7c66bbe9193a96cd21519ebd7a02644a initial_salt = 0xc3eef712c72ebb5a11a7d2432bb46365bef9f502
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 24, line 5 skipping to change at page 24, line 31
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 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 ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to
28 inclusive (using zero-based indexing). 28 inclusive (using zero-based indexing).
A packet with a long header is sampled in the same way, noting that A packet with a long header is sampled in the same way, noting that
multiple QUIC packets might be included in the same UDP datagram and multiple QUIC packets might be included in the same UDP datagram and
that each one is handled separately. that each one is handled separately.
sample_offset = 6 + len(destination_connection_id) + sample_offset = 7 + len(destination_connection_id) +
len(source_connection_id) + len(source_connection_id) +
len(payload_length) + 4 len(payload_length) + 4
if packet_type == Initial: if packet_type == Initial:
sample_offset += len(token_length) + sample_offset += len(token_length) +
len(token) len(token)
sample = packet[sample_offset..sample_offset+sample_length] sample = packet[sample_offset..sample_offset+sample_length]
5.4.3. AES-Based Header Protection 5.4.3. AES-Based Header Protection
skipping to change at page 24, line 33 skipping to change at page 25, line 11
value is used as the input to AES-ECB. In pseudocode: value is used as the input to AES-ECB. In pseudocode:
mask = AES-ECB(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 interpreted as a The first 4 bytes of the sampled ciphertext are the block counter. A
32-bit number in little-endian order and are used as the block count. ChaCha20 implementation could take a 32-bit integer in place of a
The remaining 12 bytes are interpreted as three concatenated 32-bit byte sequence, in which case the byte sequence is interpreted as a
numbers in little-endian order and used as the nonce. little-endian value.
The remaining 12 bytes are used as the nonce. A ChaCha20
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
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:
counter = DecodeLE(sample[0..3]) counter = sample[0..3]
nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15]) nonce = sample[4..15]
mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0}) 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
skipping to change at page 29, line 15 skipping to change at page 30, line 8
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
carried in Handshake packets, but because that tampering requires carried in Handshake packets, but because that tampering requires
modifying TLS handshake messages, that tampering will cause the TLS modifying TLS handshake messages, that tampering will cause the TLS
handshake to fail. handshake to fail.
8. QUIC-Specific Additions to the TLS Handshake 8. QUIC-Specific Additions to the TLS Handshake
QUIC uses the TLS handshake for more than just negotiation of QUIC uses the TLS handshake for more than just negotiation of
cryptographic parameters. The TLS handshake validates protocol cryptographic parameters. The TLS handshake provides preliminary
version selection, provides preliminary values for QUIC transport values for QUIC transport parameters and allows a server to perform
parameters, and allows a server to perform return routeability checks return routability checks on clients.
on clients.
8.1. Protocol Negotiation 8.1. Protocol Negotiation
QUIC requires that the cryptographic handshake provide authenticated QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation. TLS uses Application Layer Protocol protocol negotiation. TLS uses Application Layer Protocol
Negotiation (ALPN) [RFC7301] to select an application protocol. Negotiation (ALPN) [RFC7301] to select an application protocol.
Unless another mechanism is used for agreeing on an application Unless another mechanism is used for agreeing on an application
protocol, endpoints MUST use ALPN for this purpose. When using ALPN, protocol, endpoints MUST use ALPN for this purpose. When using ALPN,
endpoints MUST immediately close a connection (see Section 10.3 in endpoints MUST immediately close a connection (see Section 10.3 in
[QUIC-TRANSPORT]) if an application protocol is not negotiated with a [QUIC-TRANSPORT]) if an application protocol is not negotiated with a
no_application_protocol TLS alert (QUIC error code 0x178, see no_application_protocol TLS alert (QUIC error code 0x178, see
Section 4.8). While [RFC7301] only specifies that servers use this Section 4.8). While [RFC7301] only specifies that servers use this
alert, QUIC clients MUST also use it to terminate a connection when alert, QUIC clients MUST also use it to terminate a connection when
ALPN negotiation fails. ALPN negotiation fails.
An application-layer protocol MAY restrict the QUIC versions that it An application-layer protocol MAY restrict the QUIC versions that it
can operate over. Servers MUST select an application protocol can operate over. Servers MUST select an application protocol
compatible with the QUIC version that the client has selected. If compatible with the QUIC version that the client has selected. If
the server cannot select a compatible combination of application the server cannot select a compatible combination of application
protocol and QUIC version, it MUST abort the connection. A client protocol and QUIC version, it MUST abort the connection. A client
MUST abort a connection if the server picks an incompatible MUST abort a connection if the server picks an application protocol
combination of QUIC version and ALPN identifier. incompatible with the protocol version being used.
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 format for this struct. versions of QUIC might define a different format for this struct.
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 {
skipping to change at page 32, line 20 skipping to change at page 33, line 11
QUIC includes three defenses against this attack. First, the packet QUIC includes three defenses against this attack. First, the packet
containing a ClientHello MUST be padded to a minimum size. Second, containing a ClientHello MUST be padded to a minimum size. Second,
if responding to an unverified source address, the server is if responding to an unverified source address, the server is
forbidden to send more than three UDP datagrams in its first flight forbidden to send more than three UDP datagrams in its first flight
(see Section 8.1 of [QUIC-TRANSPORT]). Finally, because (see Section 8.1 of [QUIC-TRANSPORT]). Finally, because
acknowledgements of Handshake packets are authenticated, a blind acknowledgements of Handshake packets are authenticated, a blind
attacker cannot forge them. Put together, these defenses limit the attacker cannot forge them. Put together, these defenses limit the
level of amplification. level of amplification.
9.3. Peer Denial of Service 9.3. Header Protection Analysis
QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses
in some contexts, but that can be abused to cause a peer to expend
processing resources without having any observable impact on the
state of the connection. If processing is disproportionately large
in comparison to the observable effects on bandwidth or state, then
this could allow a malicious peer to exhaust processing capacity
without consequence.
While there are legitimate uses for some redundant packets,
implementations SHOULD track redundant packets and treat excessive
volumes of any non-productive packets as indicative of an attack.
9.4. Header Protection Analysis
Header protection relies on the packet protection AEAD being a Header protection relies on the packet protection AEAD being a
pseudorandom function (PRF), which is not a property that AEAD pseudorandom function (PRF), which is not a property that AEAD
algorithms guarantee. Therefore, no strong assurances about the algorithms guarantee. Therefore, no strong assurances about the
general security of this mechanism can be shown in the general case. general security of this mechanism can be shown in the general case.
The AEAD algorithms described in this document are assumed to be The AEAD algorithms described in this document are assumed to be
PRFs. PRFs.
The header protection algorithms defined in this document take the The header protection algorithms defined in this document take the
form: form:
skipping to change at page 33, line 34 skipping to change at page 34, line 12
reveal through timing side-channels that the packet number matches a reveal through timing side-channels that the packet number matches a
received packet. For authentication to be free from side-channels, received packet. For authentication to be free from side-channels,
the entire process of header protection removal, packet number the entire process of header protection removal, packet number
recovery, and packet protection removal MUST be applied together recovery, and packet protection removal MUST be applied together
without timing and other side-channels. without timing and other side-channels.
For the sending of packets, construction and protection of packet For the sending of packets, construction and protection of packet
payloads and packet numbers MUST be free from side-channels that payloads and packet numbers MUST be free from side-channels that
would reveal the packet number or its encoded size. would reveal the packet number or its encoded size.
9.5. Key Diversity 9.4. Key Diversity
In using TLS, the central key schedule of TLS is used. As a result In using TLS, the central key schedule of TLS is used. As a result
of the TLS handshake messages being integrated into the calculation of the TLS handshake messages being integrated into the calculation
of secrets, the inclusion of the QUIC transport parameters extension of secrets, the inclusion of the QUIC transport parameters extension
ensures that handshake and 1-RTT keys are not the same as those that ensures that handshake and 1-RTT keys are not the same as those that
might be produced by a server running TLS over TCP. To avoid the might be produced by a server running TLS over TCP. To avoid the
possibility of cross-protocol key synchronization, additional possibility of cross-protocol key synchronization, additional
measures are provided to improve key separation. measures are provided to improve key separation.
The QUIC packet protection keys and IVs are derived using a different The QUIC packet protection keys and IVs are derived using a different
skipping to change at page 34, line 37 skipping to change at page 35, line 15
[AES] "Advanced encryption standard (AES)", National Institute [AES] "Advanced encryption standard (AES)", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.fips.197, November 2001. DOI 10.6028/nist.fips.197, November 2001.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-22 (work and Congestion Control", draft-ietf-quic-recovery-23 (work
in progress), July 2019. in progress), September 2019.
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-22 (work in progress), July 2019. transport-23 (work in progress), September 2019.
[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>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
skipping to change at page 35, line 40 skipping to change at page 36, line 18
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", March 2016, Encryption Use in TLS", March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern [IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269, Cryptography, Second Edition", ISBN 978-1466570269,
November 2014. November 2014.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-22 (work in progress), July QUIC", draft-ietf-quic-http-23 (work in progress),
2019. September 2019.
[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 36, line 26 skipping to change at page 37, line 4
so that implementations can be verified incrementally. These packets so that implementations can be verified incrementally. These packets
use an 8-byte client-chosen Destination Connection ID of use an 8-byte client-chosen Destination Connection ID of
0x8394c8f03e515708. Values for both server and client packet 0x8394c8f03e515708. Values for both server and client packet
protection are shown together with values in hexadecimal. protection are shown together with values in hexadecimal.
A.1. Keys A.1. Keys
The labels generated by the HKDF-Expand-Label function are: The labels generated by the HKDF-Expand-Label function 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)
= 4496d3903d3f97cc5e45ac5790ddc686 = 524e374c6da8cf8b496f4bcb69678350
683c7c0067012bb09d900cc21832d596 7aafee6198b202b4bc823ebf7514a423
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)
= 8a3515a14ae3c31b9c2d6d5bc58538ca = fda3953aecc040e48b34e27ef87de3a6
5cd2baa119087143e60887428dcb52f6 098ecf0e38b7e032c5c57bcbd5975b84
key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16) key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
= 98b0d7e5e7a402c67c33f350fa65ea54 = af7fd7efebd21878ff66811248983694
iv = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12) iv = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
= 19e94387805eb0b46c03a788 = 8681359410a70bb9c92f0420
hp = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16) hp = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
= 0edd982a6ac527f2eddcbb7348dea5d7 = a980b8b4fb7d9fbc13e814c23164253d
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)
= 47b2eaea6c266e32c0697a9e2a898bdf = 554366b81912ff90be41f17e80222130
5c4fb3e5ac34f0e549bf2c58581a3811 90ab17d8149179bcadf222f29ff2ddd5
key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16) key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
= 9a8be902a9bdd91d16064ca118045fb4 = 5d51da9ee897a21b2659ccc7e5bfa577
iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12) iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
= 0a82086d32205ba22241d8dc = 5e5ae651fd1e8495af13508b
hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16) hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
= 94b9452d2b3c7c7f6da7fdd8593537fd = a8ed82e6664f865aedf6106943f95fb8
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 an 1163 byte payload: frames to make an 1163 byte payload:
060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1 060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1
4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006 4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
736572766572ff01000100000a001400 12001d00170018001901000101010201 736572766572ff01000100000a001400 12001d00170018001901000101010201
03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f 03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403 2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
05030603020308040805080604010501 060102010402050206020202002d0002 05030603020308040805080604010501 060102010402050206020202002d0002
0101001c00024001 0101001c00024001
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:
c3ff000015508394c8f03e51570800449f00000002 c3ff000017088394c8f03e5157080000449e00000002
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 = 65f354ebb400418b614f73765009c016 sample = 535064a4268a0d9d7b1c9d250ae35516
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 519bd343ff = 833b343aaa
header[0] ^= mask[0] & 0x0f header[0] ^= mask[0] & 0x0f
= c2 = c0
header[17..20] ^= mask[1..4] header[17..20] ^= mask[1..4]
= 9bd343fd = 3b343aa8
header = c2ff000015508394c8f03e51570800449f9bd343fd header = c0ff000017088394c8f03e5157080000449e3b343aa8
The resulting protected packet is: The resulting protected packet is:
c2ff000015508394c8f03e5157080044 9f9bd343fd65f354ebb400418b614f73 c0ff000017088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c
765009c0162d594777f9e6ddeb32fba3 865cffd7e26e3724d4997cdde8df34f8 9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752
868772fed2412d43046f44dc7c6adf5e e10da456d56c892c8f69594594e8dcab 4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec
edb10d591130ca464588f2834eab931b 10feb963c1947a05f57062692c242248 b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f
ad0133b31f6dcc585ba344ca5beb382f b619272e65dfccae59c08eb00b7d2a5b e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d
bccd888582df1d1aee040aea76ab4dfd cae126791e71561b1f58312edb31c164 12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6
ff1341fd2820e2399946bad901e425da e58a9859ef1825e7d757a6291d9ba6ee 11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50
1a8c836dc0027cd705bd2bc67f56bad0 024efaa3819cbb5d46cefdb7e0df3ad9 1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008
2b0689650e2b49ac29e6398bedc75554 1a3f3865bc4759bec74d721a28a0452c 0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f
1260189e8e92f844c91b27a00fc5ed6d 14d8fceb5a848bea0a3208162c7a9578 cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724
2fcf9a045b20b76710a2565372f25411 81030e4350e199e62fa4e2e0bba19ff6 87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d
6662ab8cc6815eeaa20b80d5f31c41e5 51f558d2c836a215ccff4e8afd2fec4b 7f85181a366663387ddc20551807e007 673bd7e26bf9b29b5ab10a1ca87cbb7a
fcb9ea9d051d12162f1b14842489b69d 72a307d9144fced64fc4aa21ebd310f8 d97e99eb66959c2a9bc3cbde4707ff77 20b110fa95354674e395812e47a0ae53
97cf00062e90dad5dbf04186622e6c12 96d388176585fdb395358ecfec4d95db b464dcb2d1f345df360dc227270c7506 76f6724eb479f0d2fbb6124429990457
4429f4473a76210866fd180eaeb60da4 33500c74c00aef24d77eae81755faa03 ac6c9167f40aab739998f38b9eccb24f d47c8410131bf65a52af841275d5b3d1
e71a8879937b32d31be2ba51d41b5d7a 1fbb4d952b10dd2d6ec171a3187cf3f6 880b197df2b5dea3e6de56ebce3ffb6e 9277a82082f8d9677a6767089b671ebd
4d520afad796e4188bc32d153241c083 f225b6e6b845ce9911bd3fe1eb4737b7 244c214f0bde95c2beb02cd1172d58bd f39dce56ff68eb35ab39b49b4eac7c81
1c8d55e3962871b73657b1e2cce368c7 400658d47cfd9290ed16cdc2a6e3e7dc 5ea60451d6e6ab82119118df02a58684 4a9ffe162ba006d0669ef57668cab38b
ea77fb5c6459303a32d58f62969d8f46 70ce27f591c7a59cc3e7556eda4c58a3 62f71a2523a084852cd1d079b3658dc2 f3e87949b550bab3e177cfc49ed190df
2e9f53fd7f9d60a9c05cd6238c71e3c8 2d2efabd3b5177670b8d595151d7eb44 f0630e43077c30de8f6ae081537f1e83 da537da980afa668e7b7fb25301cf741
aa401fe3b5b87bdb88dffb2bfb6d1d0d 8868a41ba96265ca7a68d06fc0b74bcc 524be3c49884b42821f17552fbd1931a 813017b6b6590a41ea18b6ba49cd48a4
ac55b038f8362b84d47f52744323d08b 46bfec8c421f991e1394938a546a7482 40bd9a3346a7623fb4ba34a3ee571e3c 731f35a7a3cf25b551a680fa68763507
a17c72be109ea4b0c71abc7d9c0ac096 0327754e1043f18a32b9fb402fc33fdc b7fde3aaf023c50b9d22da6876ba337e b5e9dd9ec3daf970242b6c5aab3aa4b2
b6a0b4fdbbddbdf0d85779879e98ef21 1d104a5271f22823f16942cfa8ace68d 96ad8b9f6832f686ef70fa938b31b4e5 ddd7364442d3ea72e73d668fb0937796
0c9e5b52297da9702d8f1de24bcd0628 4ac8aa1068fa21a82abbca7e7454b848 f462923a81a47e1cee7426ff6d922126 9b5a62ec03d6ec94d12606cb485560ba
d7de8c3d43560541a362ff4f6be06c01 15e3a733bff44417da11ae668857bba2 b574816009e96504249385bb61a819be 04f62c2066214d8360a2022beb316240
c53ba17db8c100f1b5c7c9ea960d3f3d 3b9e77c16c31a222b498a7384e286b9b b6c7d78bbe56c13082e0ca272661210a bf020bf3b5783f1426436cf9ff418405
7c45167d5703de715f9b06708403562d cff77fdf2793f94e294888cebe8da4ee 93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9
88a53e38f2430addc161e8b2e2f2d405 41d10cda9a7aa518ac14d0195d8c2012 44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14
0b4f1d47d6d0909e69c4a0e641b83c1a d4fff85af4751035bc5698b6141ecc3f a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5
bffcf2f55036880071ba118927400796 7f64468172854d140d229320d689f576 b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6
60f6c445e629d15ff2dcdff4b71a41ec 0c24bd2fd8f5ad13b2c3688e0fdb8dbc 6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e
ce42e6cf49cf60d022ccd5b19b4fd5d9 8dc10d9ce3a626851b1fdd23e1fa3a96 c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e
1f9b0333ab8d632e48c944b82bdd9e80 0fa2b2b9e31e96aee54b40edaf6b79ec eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f
211fdc95d95ef552aa532583d76a539e 988e416a0a10df2550cdeacafc3d61b0 cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da
b0a79337960a0be8cf6169e4d55fa6e7 a9c2e8efabab3da008f5bcc38c1bbabd acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc
b6c10368723da0ae83c4b1819ff54946 e7806458d80d7be2c867d46fe1f029c5 13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d
e952eb19ded16fabb19980480eb0fbcd c9be6c7803567321829dd85853396269
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:
0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988 0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002 89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
0304 0304
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:
c1ff00001505f067a5502a4262b50040740001 c1ff0000170008f067a5502a4262b50040740001
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 = 6176fa3b713f272a9bf03ee28d3c8add sample = 7002596f99ae67abf65a5852f54f58c3
mask = 5bd74a846c mask = 38168a0c25
header = caff00001505f067a5502a4262b5004074d74b header = c1ff0000170008f067a5502a4262b5004074168b
The final protected packet is then: The final protected packet is then:
caff00001505f067a5502a4262b50040 74d74b7e486176fa3b713f272a9bf03e c9ff0000170008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
e28d3c8addb4e805b3a110b663122a75 eee93c9177ac6b7a6b548e15a7b8f884 5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
65e9eab253a760779b2e6a2c574882b4 8d3a3eed696e50d04d5ec59af85261e4 537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
cdbe264bd65f2b076760c69beef23aa7 14c9a174d69034c09a2863e1e1863508 cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b9cf9bb6d091ddfc8b32d
8d4afdeab9 432348a2c413
Appendix B. Change Log Appendix B. 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.
B.1. Since draft-ietf-quic-tls-21 B.1. Since draft-ietf-quic-tls-22
o Update the salt used for Initial secrets (#2887, #2980)
B.2. Since draft-ietf-quic-tls-21
o No changes o No changes
B.2. Since draft-ietf-quic-tls-20 B.3. Since draft-ietf-quic-tls-20
o Mandate the use of the QUIC transport parameters extension (#2528, o Mandate the use of the QUIC transport parameters extension (#2528,
#2560) #2560)
o Define handshake completion and confirmation; define clearer rules o 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)
B.3. Since draft-ietf-quic-tls-18 B.4. Since draft-ietf-quic-tls-18
o Increased the set of permissible frames in 0-RTT (#2344, #2355) o Increased the set of permissible frames in 0-RTT (#2344, #2355)
o Transport parameter extension is mandatory (#2528, #2560) o Transport parameter extension is mandatory (#2528, #2560)
B.4. Since draft-ietf-quic-tls-17 B.5. Since draft-ietf-quic-tls-17
o Endpoints discard initial keys as soon as handshake keys are o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
o Use of ALPN or equivalent is mandatory (#2263, #2284) o Use of ALPN or equivalent is mandatory (#2263, #2284)
B.5. Since draft-ietf-quic-tls-14 B.6. Since draft-ietf-quic-tls-14
o Update the salt used for Initial secrets (#1970) o Update the salt used for Initial secrets (#1970)
o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
o Change header protection o 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 41, line 35 skipping to change at page 41, line 35
o TLS provides an AEAD and KDF function (#2046) o 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)
o Initial keys are discarded once Handshake are avaialble (#1951, o Initial keys are discarded once Handshake are avaialble (#1951,
#2045) #2045)
B.6. Since draft-ietf-quic-tls-13 B.7. Since draft-ietf-quic-tls-13
o Updated to TLS 1.3 final (#1660) o Updated to TLS 1.3 final (#1660)
B.7. Since draft-ietf-quic-tls-12 B.8. Since draft-ietf-quic-tls-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o 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)
o Changed codepoint of TLS extension (#1395, #1402) o Changed codepoint of TLS extension (#1395, #1402)
B.8. Since draft-ietf-quic-tls-11 B.9. Since draft-ietf-quic-tls-11
o Encrypted packet numbers. o Encrypted packet numbers.
B.9. Since draft-ietf-quic-tls-10 B.10. Since draft-ietf-quic-tls-10
o No significant changes. o No significant changes.
B.10. Since draft-ietf-quic-tls-09 B.11. Since draft-ietf-quic-tls-09
o Cleaned up key schedule and updated the salt used for handshake o Cleaned up key schedule and updated the salt used for handshake
packet protection (#1077) packet protection (#1077)
B.11. Since draft-ietf-quic-tls-08 B.12. Since draft-ietf-quic-tls-08
o Specify value for max_early_data_size to enable 0-RTT (#942) o Specify value for max_early_data_size to enable 0-RTT (#942)
o Update key derivation function (#1003, #1004) o Update key derivation function (#1003, #1004)
B.12. Since draft-ietf-quic-tls-07 B.13. Since draft-ietf-quic-tls-07
o Handshake errors can be reported with CONNECTION_CLOSE (#608, o Handshake errors can be reported with CONNECTION_CLOSE (#608,
#891) #891)
B.13. Since draft-ietf-quic-tls-05 B.14. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
B.14. Since draft-ietf-quic-tls-04 B.15. Since draft-ietf-quic-tls-04
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.15. Since draft-ietf-quic-tls-03 B.16. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
B.16. Since draft-ietf-quic-tls-02 B.17. Since draft-ietf-quic-tls-02
o Updates to match changes in transport draft o Updates to match changes in transport draft
B.17. Since draft-ietf-quic-tls-01 B.18. Since draft-ietf-quic-tls-01
o Use TLS alerts to signal TLS errors (#272, #374) o Use TLS alerts to signal TLS errors (#272, #374)
o Require ClientHello to fit in a single packet (#338) o Require ClientHello to fit in a single packet (#338)
o The second client handshake flight is now sent in the clear (#262, o The second client handshake flight is now sent in the clear (#262,
#337) #337)
o The QUIC header is included as AEAD Associated Data (#226, #243, o The QUIC header is included as AEAD Associated Data (#226, #243,
#302) #302)
skipping to change at page 43, line 30 skipping to change at page 43, line 30
o Require at least TLS 1.3 (#138) o Require at least TLS 1.3 (#138)
o Define transport parameters as a TLS extension (#122) o Define transport parameters as a TLS extension (#122)
o Define handling for protected packets before the handshake o Define handling for protected packets before the handshake
completes (#39) completes (#39)
o Decouple QUIC version and ALPN (#12) o Decouple QUIC version and ALPN (#12)
B.18. Since draft-ietf-quic-tls-00 B.19. Since draft-ietf-quic-tls-00
o Changed bit used to signal key phase o Changed bit used to signal key phase
o Updated key phase markings during the handshake o Updated key phase markings during the handshake
o Added TLS interface requirements section o Added TLS interface requirements section
o Moved to use of TLS exporters for key derivation o Moved to use of TLS exporters for key derivation
o Moved TLS error code definitions into this document o Moved TLS error code definitions into this document
B.19. Since draft-thomson-quic-tls-01 B.20. Since draft-thomson-quic-tls-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added status note o Added status note
Acknowledgments Acknowledgments
This document has benefited from input from Dragana Damjanovic, This document has benefited from input from Dragana Damjanovic,
 End of changes. 79 change blocks. 
185 lines changed or deleted 212 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/