draft-ietf-quic-tls-24.txt   draft-ietf-quic-tls-25.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: May 7, 2020 sn3rd Expires: 25 July 2020 sn3rd
November 04, 2019 22 January 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-24 draft-ietf-quic-tls-25
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
https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. https://mailarchive.ietf.org/arch/search/?email_list=quic
(https://mailarchive.ietf.org/arch/search/?email_list=quic).
Working Group information can be found at https://github.com/quicwg Working Group information can be found at https://github.com/quicwg
[2]; source code and issues list for this draft can be found at (https://github.com/quicwg); source code and issues list for this
https://github.com/quicwg/base-drafts/labels/-tls [3]. draft can be found at https://github.com/quicwg/base-drafts/labels/-
tls (https://github.com/quicwg/base-drafts/labels/-tls).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 7, 2020. This Internet-Draft will expire on 25 July 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8 4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8
4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 10 4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10 4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10
skipping to change at page 2, line 37 skipping to change at page 2, line 36
4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13 4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13
4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15
4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15 4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15
4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 16 4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 16
4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16 4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16
4.7. Validating 0-RTT Configuration . . . . . . . . . . . . . 17 4.7. Validating 0-RTT Configuration . . . . . . . . . . . . . 17
4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 17 4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 17
4.9. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 18 4.9. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 18
4.10. Discarding Unused Keys . . . . . . . . . . . . . . . . . 18 4.10. Discarding Unused Keys . . . . . . . . . . . . . . . . . 18
4.10.1. Discarding Initial Keys . . . . . . . . . . . . . . 18 4.10.1. Discarding Initial Keys . . . . . . . . . . . . . . 19
4.10.2. Discarding Handshake Keys . . . . . . . . . . . . . 19 4.10.2. Discarding Handshake Keys . . . . . . . . . . . . . 19
4.10.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 19 4.10.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 19
5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 20 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 20 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 20
5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 20 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 20
5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 21 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 23 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 23
5.4.1. Header Protection Application . . . . . . . . . . . . 23 5.4.1. Header Protection Application . . . . . . . . . . . . 23
5.4.2. Header Protection Sample . . . . . . . . . . . . . . 25 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 25
5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 26 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 26
5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 26 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 26
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 27 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 27
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 27 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 27
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 28 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 28
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 29
6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 29 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Responding to a Key Update . . . . . . . . . . . . . . . 30 6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 31
6.3. Timing of Receive Key Generation . . . . . . . . . . . . 31 6.2. Responding to a Key Update . . . . . . . . . . . . . . . 32
6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 32 6.3. Timing of Receive Key Generation . . . . . . . . . . . . 33
6.5. Receiving with Different Keys . . . . . . . . . . . . . . 32 6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 33
6.6. Key Update Frequency . . . . . . . . . . . . . . . . . . 33 6.5. Receiving with Different Keys . . . . . . . . . . . . . . 34
6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 33 6.6. Key Update Frequency . . . . . . . . . . . . . . . . . . 35
7. Security of Initial Messages . . . . . . . . . . . . . . . . 33 6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 35
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 34 7. Security of Initial Messages . . . . . . . . . . . . . . . . 35
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 34 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 35
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 34 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 36
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 35 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 37
9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 37 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 37
9.3. Header Protection Analysis . . . . . . . . . . . . . . . 37 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 38
9.4. Header Protection Timing Side-Channels . . . . . . . . . 38 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 39
9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 39 9.4. Header Protection Timing Side-Channels . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11.1. Normative References . . . . . . . . . . . . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Informative References . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 41
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Sample Initial Packet Protection . . . . . . . . . . 41 Appendix A. Sample Initial Packet Protection . . . . . . . . . . 43
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 43 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 44
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 44 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 46
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47
B.1. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 45 B.1. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 47
B.2. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 45 B.2. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 47
B.3. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 46 B.3. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 48
B.4. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 46 B.4. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 48
B.5. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 46 B.5. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 48
B.6. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 46 B.6. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 48
B.7. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 46 B.7. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 48
B.8. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 47 B.8. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 48
B.9. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 47 B.9. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 49
B.10. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 47 B.10. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 49
B.11. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 47 B.11. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 49
B.12. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 47 B.12. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 49
B.13. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 47 B.13. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 49
B.14. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 47 B.14. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 49
B.15. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 48 B.15. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 50
B.16. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 48 B.16. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 50
B.17. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 48 B.17. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 50
B.18. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 48 B.18. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 50
B.19. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 48 B.19. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 50
B.20. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 48 B.20. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 50
B.21. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 49 B.21. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 50
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 B.22. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 51
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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 5, line 15 skipping to change at page 5, line 15
+-------------+------------+--------------+---------+ +-------------+------------+--------------+---------+
Handshake | | | Application | | Handshake | | | Application | |
Layer | Handshake | Alerts | Data | ... | Layer | Handshake | Alerts | Data | ... |
| | | | | | | | | |
+-------------+------------+--------------+---------+ +-------------+------------+--------------+---------+
Record | | Record | |
Layer | Records | Layer | Records |
| | | |
+---------------------------------------------------+ +---------------------------------------------------+
Figure 1: TLS Layers Figure 1: TLS Layers
Each Handshake layer message (e.g., Handshake, Alerts, and Each Handshake layer message (e.g., Handshake, Alerts, and
Application Data) is carried as a series of typed TLS records by the Application Data) is carried as a series of typed TLS records by the
Record layer. Records are individually cryptographically protected Record layer. Records are individually cryptographically protected
and then transmitted over a reliable transport (typically TCP) which and then transmitted over a reliable transport (typically TCP) which
provides sequencing and guaranteed delivery. provides sequencing and guaranteed delivery.
The TLS authenticated key exchange occurs between two endpoints: The TLS authenticated key exchange occurs between two endpoints:
client and server. The client initiates the exchange and the server client and server. The client initiates the exchange and the server
responds. If the key exchange completes successfully, both client responds. If the key exchange completes successfully, both client
skipping to change at page 5, line 44 skipping to change at page 5, line 44
able to learn and authenticate an identity for the client. TLS able to learn and authenticate an identity for the client. TLS
supports X.509 [RFC5280] certificate-based authentication for both supports X.509 [RFC5280] certificate-based authentication for both
server and client. server and client.
The TLS key exchange is resistant to tampering by attackers and it The TLS key exchange is resistant to tampering by attackers and it
produces shared secrets that cannot be controlled by either produces shared secrets that cannot be controlled by either
participating peer. participating peer.
TLS provides two basic handshake modes of interest to QUIC: TLS provides two basic handshake modes of interest to QUIC:
o 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.
o A 0-RTT handshake in which the client uses information it has * A 0-RTT handshake in which the client uses information it has
previously learned about the server to send Application Data previously learned about the server to send Application Data
immediately. This Application Data can be replayed by an attacker immediately. This Application Data can be replayed by an attacker
so it MUST NOT carry a self-contained trigger for any non- so it MUST NOT carry a self-contained trigger for any non-
idempotent action. idempotent action.
A simplified TLS handshake with 0-RTT application data is shown in A simplified TLS handshake with 0-RTT application data is shown in
Figure 2. Note that this omits the EndOfEarlyData message, which is Figure 2. Note that this omits the EndOfEarlyData message, which is
not used in QUIC (see Section 8.3). Likewise, neither not used in QUIC (see Section 8.3). Likewise, neither
ChangeCipherSpec nor KeyUpdate messages are used by QUIC; ChangeCipherSpec nor KeyUpdate messages are used by QUIC;
ChangeCipherSpec is redundant in TLS 1.3 and QUIC has defined its own ChangeCipherSpec is redundant in TLS 1.3 and QUIC has defined its own
skipping to change at page 6, line 31 skipping to change at page 6, line 31
<-------- [Application Data] <-------- [Application Data]
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
() Indicates messages protected by Early Data (0-RTT) Keys () Indicates messages protected by Early Data (0-RTT) Keys
{} Indicates messages protected using Handshake Keys {} Indicates messages protected using Handshake Keys
[] Indicates messages protected using Application Data [] Indicates messages protected using Application Data
(1-RTT) Keys (1-RTT) Keys
Figure 2: TLS Handshake with 0-RTT Figure 2: TLS Handshake with 0-RTT
Data is protected using a number of encryption levels: Data is protected using a number of encryption levels:
o Initial Keys * Initial Keys
o Early Data (0-RTT) Keys * Early Data (0-RTT) Keys
o Handshake Keys * Handshake Keys
o Application Data (1-RTT) Keys * Application Data (1-RTT) Keys
Application Data may appear only in the Early Data and Application Application Data may appear only in the Early Data and Application
Data levels. Handshake and Alert messages may appear in any level. Data levels. Handshake and Alert messages may appear in any level.
The 0-RTT handshake is only possible if the client and server have The 0-RTT handshake is only possible if the client and server have
previously communicated. In the 1-RTT handshake, the client is previously communicated. In the 1-RTT handshake, the client is
unable to send protected Application Data until it has received all unable to send protected Application Data until it has received all
of the Handshake messages sent by the server. of the Handshake messages sent by the server.
3. Protocol Overview 3. Protocol Overview
skipping to change at page 7, line 41 skipping to change at page 7, line 41
QUIC also relies on TLS for authentication and negotiation of QUIC also relies on TLS for authentication and negotiation of
parameters that are critical to security and performance. parameters that are critical to security and performance.
Rather than a strict layering, these two protocols cooperate: QUIC Rather than a strict layering, these two protocols cooperate: QUIC
uses the TLS handshake; TLS uses the reliability, ordered delivery, uses the TLS handshake; TLS uses the reliability, ordered delivery,
and record layer provided by QUIC. and record layer provided by QUIC.
At a high level, there are two main interactions between the TLS and At a high level, there are two main interactions between the TLS and
QUIC components: QUIC components:
o The TLS component sends and receives messages via the QUIC * The TLS component sends and receives messages via the QUIC
component, with QUIC providing a reliable stream abstraction to component, with QUIC providing a reliable stream abstraction to
TLS. TLS.
o The TLS component provides a series of updates to the QUIC * The TLS component provides a series of updates to the QUIC
component, including (a) new packet protection keys to install (b) component, including (a) new packet protection keys to install (b)
state changes such as handshake completion, the server state changes such as handshake completion, the server
certificate, etc. certificate, etc.
Figure 4 shows these interactions in more detail, with the QUIC Figure 4 shows these interactions in more detail, with the QUIC
packet protection being called out specially. packet protection being called out specially.
+------------+ +------------+ +------------+ +------------+
| |<---- Handshake Messages ----->| | | |<---- Handshake Messages ----->| |
| |<- Validate 0-RTT parameters ->| | | |<- Validate 0-RTT parameters ->| |
skipping to change at page 9, line 5 skipping to change at page 9, line 5
QUIC packet as long as they are associated with the same encryption QUIC packet as long as they are associated with the same encryption
level. For instance, an implementation might bundle a Handshake level. For instance, an implementation might bundle a Handshake
message and an ACK for some Handshake data into the same packet. message and an ACK for some Handshake data into the same packet.
Some frames are prohibited in different encryption levels, others Some frames are prohibited in different encryption levels, others
cannot be sent. The rules here generalize those of TLS, in that cannot be sent. The rules here generalize those of TLS, in that
frames associated with establishing the connection can usually appear frames associated with establishing the connection can usually appear
at any encryption level, whereas those associated with transferring at any encryption level, whereas those associated with transferring
data can only appear in the 0-RTT and 1-RTT encryption levels: data can only appear in the 0-RTT and 1-RTT encryption levels:
o PADDING and PING frames MAY appear in packets of any encryption * PADDING and PING frames MAY appear in packets of any encryption
level. level.
o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any * CRYPTO frames and CONNECTION_CLOSE frames signaling errors at the
encryption level except 0-RTT. QUIC layer (type 0x1c) MAY appear in packets of any encryption
level except 0-RTT.
o ACK frames MAY appear in packets of any encryption level other * CONNECTION_CLOSE frames signaling application errors (type 0x1d)
MUST only be sent in packets at the 1-RTT encryption level.
* ACK frames MAY appear in packets of any encryption level other
than 0-RTT, but can only acknowledge packets which appeared in than 0-RTT, but can only acknowledge packets which appeared in
that packet number space. that packet number space.
o All other frame types MUST only be sent in the 0-RTT and 1-RTT * All other frame types MUST only be sent in the 0-RTT and 1-RTT
levels. levels.
Note that it is not possible to send the following frames in 0-RTT Note that it is not possible to send the following frames in 0-RTT
for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
RETIRE_CONNECTION_ID. RETIRE_CONNECTION_ID.
Because packets could be reordered on the wire, QUIC uses the packet Because packets could be reordered on the wire, QUIC uses the packet
type to indicate which level a given packet was encrypted under, as type to indicate which level a given packet was encrypted under, as
shown in Table 1. When multiple packets of different encryption shown in Table 1. When multiple packets of different encryption
levels need to be sent, endpoints SHOULD use coalesced packets to levels need to be sent, endpoints SHOULD use coalesced packets to
send them in the same UDP datagram. send them in the same UDP datagram.
+---------------------+------------------+-----------+ +---------------------+------------------+-----------+
| Packet Type | Encryption Level | PN Space | | Packet Type | Encryption Level | PN Space |
+---------------------+------------------+-----------+ +=====================+==================+===========+
| Initial | Initial secrets | Initial | | Initial | Initial secrets | Initial |
| | | | +---------------------+------------------+-----------+
| 0-RTT Protected | 0-RTT | 0/1-RTT | | 0-RTT Protected | 0-RTT | 0/1-RTT |
| | | | +---------------------+------------------+-----------+
| Handshake | Handshake | Handshake | | Handshake | Handshake | Handshake |
| | | | +---------------------+------------------+-----------+
| Retry | N/A | N/A | | Retry | N/A | N/A |
| | | | +---------------------+------------------+-----------+
| Version Negotiation | N/A | N/A | | Version Negotiation | N/A | N/A |
| | | | +---------------------+------------------+-----------+
| Short Header | 1-RTT | 0/1-RTT | | Short Header | 1-RTT | 0/1-RTT |
+---------------------+------------------+-----------+ +---------------------+------------------+-----------+
Table 1: Encryption Levels by Packet Type Table 1: Encryption Levels by Packet Type
Section 17 of [QUIC-TRANSPORT] shows how packets at the various Section 17 of [QUIC-TRANSPORT] shows how packets at the various
encryption levels fit into the handshake process. encryption levels fit into the handshake process.
4.1. Interface to TLS 4.1. Interface to TLS
As shown in Figure 4, the interface from QUIC to TLS consists of four As shown in Figure 4, the interface from QUIC to TLS consists of four
primary functions: primary functions:
o Sending and receiving handshake messages * Sending and receiving handshake messages
o Processing stored transport and application state from a resumed * Processing stored transport and application state from a resumed
session and determining if it is valid to accept early data session and determining if it is valid to accept early data
o Rekeying (both transmit and receive) * Rekeying (both transmit and receive)
o Handshake state updates * Handshake state updates
Additional functions might be needed to configure TLS. Additional functions might be needed to configure TLS.
4.1.1. Handshake Complete 4.1.1. Handshake Complete
In this document, the TLS handshake is considered complete when the In this document, the TLS handshake is considered complete when the
TLS stack has reported that the handshake is complete. This happens TLS stack has reported that the handshake is complete. This happens
when the TLS stack has both sent a Finished message and verified the when the TLS stack has both sent a Finished message and verified the
peer's Finished message. Verifying the peer's Finished provides the peer's Finished message. Verifying the peer's Finished provides the
endpoints with an assurance that previous handshake messages have not endpoints with an assurance that previous handshake messages have not
been modified. Note that the handshake does not complete at both been modified. Note that the handshake does not complete at both
endpoints simultaneously. Consequently, any requirement that is endpoints simultaneously. Consequently, any requirement that is
based on the completion of the handshake depends on the perspective based on the completion of the handshake depends on the perspective
of the endpoint in question. of the endpoint in question.
4.1.2. Handshake Confirmed 4.1.2. Handshake Confirmed
In this document, the TLS handshake is considered confirmed at an In this document, the TLS handshake is considered confirmed at the
endpoint when the following two conditions are met: the handshake is server when the handshake completes. At the client, the handshake is
complete, and the endpoint has received an acknowledgment for a considered confirmed when a HANDSHAKE_DONE frame is received.
packet sent with 1-RTT keys. This second condition can be
implemented by recording the lowest packet number sent with 1-RTT A client MAY consider the handshake to be confirmed when it receives
keys, and the highest value of the Largest Acknowledged field in any an acknowledgement for a 1-RTT packet. This can be implemented by
received 1-RTT ACK frame: once the latter is higher than or equal to recording the lowest packet number sent with 1-RTT keys, and
the former, the handshake is confirmed. comparing it to the Largest Acknowledged field in any received 1-RTT
ACK frame: once the latter is greater than or equal to the former,
the handshake is confirmed.
4.1.3. Sending and Receiving Handshake Messages 4.1.3. Sending and Receiving Handshake Messages
In order to drive the handshake, TLS depends on being able to send In order to drive the handshake, TLS depends on being able to send
and receive handshake messages. There are two basic functions on and receive handshake messages. There are two basic functions on
this interface: one where QUIC requests handshake messages and one this interface: one where QUIC requests handshake messages and one
where QUIC provides handshake packets. where QUIC provides handshake packets.
Before starting the handshake QUIC provides TLS with the transport Before starting the handshake QUIC provides TLS with the transport
parameters (see Section 8.2) that it wishes to carry. parameters (see Section 8.2) that it wishes to carry.
skipping to change at page 11, line 32 skipping to change at page 11, line 35
QUIC is only capable of conveying TLS handshake records in CRYPTO QUIC is only capable of conveying TLS handshake records in CRYPTO
frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error
codes; see Section 4.9. TLS application data and other message types codes; see Section 4.9. TLS application data and other message types
cannot be carried by QUIC at any encryption level and is an error if cannot be carried by QUIC at any encryption level and is an error if
they are received from the TLS stack. they are received from the TLS stack.
When an endpoint receives a QUIC packet containing a CRYPTO frame When an endpoint receives a QUIC packet containing a CRYPTO frame
from the network, it proceeds as follows: from the network, it proceeds as follows:
o If the packet was in the TLS receiving encryption level, sequence * If the packet was in the TLS receiving encryption level, sequence
the data into the input flow as usual. As with STREAM frames, the the data into the input flow as usual. As with STREAM frames, the
offset is used to find the proper location in the data sequence. offset is used to find the proper location in the data sequence.
If the result of this process is that new data is available, then If the result of this process is that new data is available, then
it is delivered to TLS in order. it is delivered to TLS in order.
o If the packet is from a previously installed encryption level, it * If the packet is from a previously installed encryption level, it
MUST not contain data which extends past the end of previously MUST not contain data which extends past the end of previously
received data in that flow. Implementations MUST treat any received data in that flow. Implementations MUST treat any
violations of this requirement as a connection error of type violations of this requirement as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
o If the packet is from a new encryption level, it is saved for * If the packet is from a new encryption level, it is saved for
later processing by TLS. Once TLS moves to receiving from this later processing by TLS. Once TLS moves to receiving from this
encryption level, saved data can be provided. When providing data encryption level, saved data can be provided. When providing data
from any new encryption level to TLS, if there is data from a from any new encryption level to TLS, if there is data from a
previous encryption level that TLS has not consumed, this MUST be previous encryption level that TLS has not consumed, this MUST be
treated as a connection error of type PROTOCOL_VIOLATION. treated as a connection error of type PROTOCOL_VIOLATION.
Each time that TLS is provided with new data, new handshake bytes are Each time that TLS is provided with new data, new handshake bytes are
requested from TLS. TLS might not provide any bytes if the handshake requested from TLS. TLS might not provide any bytes if the handshake
messages it has received are incomplete or it has no data to send. messages it has received are incomplete or it has no data to send.
skipping to change at page 12, line 39 skipping to change at page 12, line 39
with those keys. Separately, as keys at a given encryption level with those keys. Separately, as keys at a given encryption level
become available to TLS, TLS indicates to QUIC that reading or become available to TLS, TLS indicates to QUIC that reading or
writing keys at that encryption level are available. These events writing keys at that encryption level are available. These events
are not asynchronous; they always occur immediately after TLS is are not asynchronous; they always occur immediately after TLS is
provided with new handshake bytes, or after TLS produces handshake provided with new handshake bytes, or after TLS produces handshake
bytes. 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 * A secret
o An Authenticated Encryption with Associated Data (AEAD) function * An Authenticated Encryption with Associated Data (AEAD) function
o A Key Derivation Function (KDF) * A Key Derivation Function (KDF)
These values are based on the values that TLS negotiates and are used These values are based on the values that TLS negotiates and are used
by QUIC to generate packet and header protection keys (see Section 5 by QUIC to generate packet and header protection keys (see Section 5
and Section 5.4). and Section 5.4).
If 0-RTT is possible, it is ready after the client sends a TLS If 0-RTT is possible, it is ready after the client sends a TLS
ClientHello message or the server receives that message. After ClientHello message or the server receives that message. After
providing a QUIC client with the first handshake bytes, the TLS stack providing a QUIC client with the first handshake bytes, the TLS stack
might signal the change to 0-RTT keys. On the server, after might signal the change to 0-RTT keys. On the server, after
receiving handshake bytes that contain a ClientHello message, a TLS receiving handshake bytes that contain a ClientHello message, a TLS
skipping to change at page 14, line 35 skipping to change at page 14, line 35
Handshake -----------> Handshake ----------->
Handshake Received Handshake Received
Install rx 1-RTT keys Install rx 1-RTT keys
Handshake Complete Handshake Complete
Install 1-RTT keys Install 1-RTT keys
1-RTT ---------------> 1-RTT --------------->
Get Handshake Get Handshake
<--------------- 1-RTT <--------------- 1-RTT
Handshake Received Handshake Received
Figure 5: Interaction Summary between QUIC and TLS Figure 5: Interaction Summary between QUIC and TLS
Figure 5 shows the multiple packets that form a single "flight" of Figure 5 shows the multiple packets that form a single "flight" of
messages being processed individually, to show what incoming messages messages being processed individually, to show what incoming messages
trigger different actions. New handshake messages are requested trigger different actions. New handshake messages are requested
after all incoming packets have been processed. This process might after all incoming packets have been processed. This process might
vary depending on how QUIC implementations and the packets they vary depending on how QUIC implementations and the packets they
receive are structured. receive are structured.
4.2. TLS Version 4.2. TLS Version
skipping to change at page 19, line 20 skipping to change at page 19, line 26
Thus, a client MUST discard Initial keys when it first sends a Thus, a client MUST discard Initial keys when it first sends a
Handshake packet and a server MUST discard Initial keys when it first Handshake packet and a server MUST discard Initial keys when it first
successfully processes a Handshake packet. Endpoints MUST NOT send successfully processes a Handshake packet. Endpoints MUST NOT send
Initial packets after this point. Initial packets after this point.
This results in abandoning loss recovery state for the Initial This results in abandoning loss recovery state for the Initial
encryption level and ignoring any outstanding Initial packets. encryption level and ignoring any outstanding Initial packets.
4.10.2. Discarding Handshake Keys 4.10.2. Discarding Handshake Keys
An endpoint MUST NOT discard its handshake keys until the TLS An endpoint MUST discard its handshake keys when the TLS handshake is
handshake is confirmed (Section 4.1.2). An endpoint SHOULD discard confirmed (Section 4.1.2). The server MUST send a HANDSHAKE_DONE
its handshake keys as soon as it has confirmed the handshake. Most frame as soon as it completes the handshake.
application protocols will send data after the handshake, resulting
in acknowledgements that allow both endpoints to discard their
handshake keys promptly. Endpoints that do not have reason to send
immediately after completing the handshake MAY send ack-eliciting
frames, such as PING, which will cause the handshake to be confirmed
when they are acknowledged.
4.10.3. Discarding 0-RTT Keys 4.10.3. Discarding 0-RTT Keys
0-RTT and 1-RTT packets share the same packet number space, and 0-RTT and 1-RTT packets share the same packet number space, and
clients do not send 0-RTT packets after sending a 1-RTT packet clients do not send 0-RTT packets after sending a 1-RTT packet
(Section 5.6). (Section 5.6).
Therefore, a client SHOULD discard 0-RTT keys as soon as it installs Therefore, a client SHOULD discard 0-RTT keys as soon as it installs
1-RTT keys, since they have no use after that moment. 1-RTT keys, since they have no use after that moment.
skipping to change at page 24, line 18 skipping to change at page 24, line 18
if (packet[0] & 0x80) == 0x80: if (packet[0] & 0x80) == 0x80:
# Long header: 4 bits masked # Long header: 4 bits masked
packet[0] ^= mask[0] & 0x0f packet[0] ^= mask[0] & 0x0f
else: else:
# Short header: 5 bits masked # Short header: 5 bits masked
packet[0] ^= mask[0] & 0x1f packet[0] ^= mask[0] & 0x1f
# pn_offset is the start of the Packet Number field. # pn_offset is the start of the Packet Number field.
packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length] packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
Figure 6: Header Protection Pseudocode Figure 6: Header Protection Pseudocode
Figure 7 shows the protected fields of long and short headers marked Figure 7 shows the protected fields of long and short headers marked
with an E. Figure 7 also shows the sampled fields. with an E. Figure 7 also shows the sampled fields.
Long Header: Long Header:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1|T T|E E E E| |1|1|T T|E E E E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version -> Length Fields ... | Version -> Length Fields ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 11 skipping to change at page 28, line 11
handshake is complete. The 1-RTT keys necessary to remove packet handshake is complete. The 1-RTT keys necessary to remove packet
protection cannot be derived until the client receives all server protection cannot be derived until the client receives all server
handshake messages. handshake messages.
5.7. Receiving Out-of-Order Protected Frames 5.7. Receiving Out-of-Order Protected Frames
Due to reordering and loss, protected packets might be received by an Due to reordering and loss, protected packets might be received by an
endpoint before the final TLS handshake messages are received. A endpoint before the final TLS handshake messages are received. A
client will be unable to decrypt 1-RTT packets from the server, client will be unable to decrypt 1-RTT packets from the server,
whereas a server will be able to decrypt 1-RTT packets from the whereas a server will be able to decrypt 1-RTT packets from the
client. client. Endpoints in either role MUST NOT decrypt 1-RTT packets from
their peer prior to completing the handshake.
Even though 1-RTT keys are available to a server after receiving the Even though 1-RTT keys are available to a server after receiving the
first handshake messages from a client, it is missing assurances on first handshake messages from a client, it is missing assurances on
the client state: the client state:
o The client is not authenticated, unless the server has chosen to * The client is not authenticated, unless the server has chosen to
use a pre-shared key and validated the client's pre-shared key use a pre-shared key and validated the client's pre-shared key
binder; see Section 4.2.11 of [TLS13]. binder; see Section 4.2.11 of [TLS13].
o The client has not demonstrated liveness, unless a RETRY packet * The client has not demonstrated liveness, unless a RETRY packet
was used. was used.
o Any received 0-RTT data that the server responds to might be due * Any received 0-RTT data that the server responds to might be due
to a replay attack. to a replay attack.
Therefore, the server's use of 1-RTT keys is limited before the Therefore, the server's use of 1-RTT keys MUST be limited to sending
handshake is complete. A server MUST NOT process data from incoming data before the handshake is complete. A server MUST NOT process
1-RTT protected packets before the TLS handshake is complete. incoming 1-RTT protected packets before the TLS handshake is
Because sending acknowledgments indicates that all frames in a packet complete. Because sending acknowledgments indicates that all frames
have been processed, a server cannot send acknowledgments for 1-RTT in a packet have been processed, a server cannot send acknowledgments
packets until the TLS handshake is complete. Received packets for 1-RTT packets until the TLS handshake is complete. Received
protected with 1-RTT keys MAY be stored and later decrypted and used packets protected with 1-RTT keys MAY be stored and later decrypted
once the handshake is complete. and used once the handshake is complete.
Note: TLS implementations might provide all 1-RTT secrets prior to
handshake completion. Even where QUIC implementations have 1-RTT
read keys, those keys cannot be used prior to completing the
handshake.
The requirement for the server to wait for the client Finished The requirement for the server to wait for the client Finished
message creates a dependency on that message being delivered. A message creates a dependency on that message being delivered. A
client can avoid the potential for head-of-line blocking that this client can avoid the potential for head-of-line blocking that this
implies by sending its 1-RTT packets coalesced with a handshake implies by sending its 1-RTT packets coalesced with a handshake
packet containing a copy of the CRYPTO frame that carries the packet containing a copy of the CRYPTO frame that carries the
Finished message, until one of the handshake packets is acknowledged. Finished message, until one of the handshake packets is acknowledged.
This enables immediate server processing for those packets. This enables immediate server processing for those packets.
A server could receive packets protected with 0-RTT keys prior to A server could receive packets protected with 0-RTT keys prior to
receiving a TLS ClientHello. The server MAY retain these packets for receiving a TLS ClientHello. The server MAY retain these packets for
later decryption in anticipation of receiving a ClientHello. later decryption in anticipation of receiving a ClientHello.
5.8. Retry Packet Integrity
Retry packets (see the Retry Packet section of [QUIC-TRANSPORT])
carry a Retry Integrity Tag that provides two properties: it allows
discarding packets that have accidentally been corrupted by the
network, and it diminishes off-path attackers' ability to send valid
Retry packets.
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:
* The secret key, K, is 128 bits equal to
0x4d32ecdb2a2133c841e4043df27d4430.
* The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575.
* The plaintext, P, is empty.
* The associated data, A, is the contents of the Retry Pseudo-
Packet, as illustrated in Figure 8:
The secret key and the nonce are values derived by calling HKDF-
Expand-Label using
0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as
the secret, with labels being "quic key" and "quic iv" (Section 5.1).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| 3 | Unused|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Retry Pseudo-Packet
The Retry Pseudo-Packet is not sent over the wire. It is computed by
taking the transmitted Retry packet, removing the Retry Integrity Tag
and prepending the two following fields:
ODCID Len: The ODCID Len contains the length in bytes of the
Original Destination Connection ID field that follows it, encoded
as an 8-bit unsigned integer.
Original Destination Connection ID: The Original Destination
Connection ID contains the value of the Destination Connection ID
from the Initial packet that this Retry is in response to. The
length of this field is given in ODCID Len. The presence of this
field mitigates an off-path attacker's ability to inject a Retry
packet.
6. Key Update 6. Key Update
Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY
initiate a key update. initiate a key update.
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.
skipping to change at page 29, line 21 skipping to change at page 30, line 42
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 TLS KeyUpdate message. Endpoints MUST
NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt
of a TLS KeyUpdate message as a connection error of type 0x10a, of a TLS KeyUpdate message as a connection error of type 0x10a,
equivalent to a fatal TLS alert of unexpected_message (see equivalent to a fatal TLS alert of unexpected_message (see
Section 4.9). Section 4.9).
Figure 8 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
... Update to @N ... Update to @N
@N [1] QUIC Packets @N [1] QUIC Packets
skipping to change at page 29, line 46 skipping to change at page 31, line 25
QUIC Packets [1] @N QUIC Packets [1] @N
containing ACK containing ACK
<-------- <--------
... Key Update Permitted ... Key Update Permitted
@N [1] QUIC Packets @N [1] QUIC Packets
containing ACK for @N packets containing ACK for @N packets
--------> -------->
Key Update Permitted ... Key Update Permitted ...
Figure 8: Key Update Figure 9: Key Update
6.1. Initiating a Key Update 6.1. Initiating a Key Update
Endpoints maintain separate read and write secrets for packet Endpoints maintain separate read and write secrets for packet
protection. An endpoint initiates a key update by updating its protection. An endpoint initiates a key update by updating its
packet protection write secret and using that to protect new packets. packet protection write secret and using that to protect new packets.
The endpoint creates a new write secret from the existing write The endpoint creates a new write secret from the existing write
secret as performed in Section 7.2 of [TLS13]. This uses the KDF secret as performed in Section 7.2 of [TLS13]. This uses the KDF
function provided by TLS with a label of "quic ku". The function provided by TLS with a label of "quic ku". The
corresponding key and IV are created from that secret as defined in corresponding key and IV are created from that secret as defined in
Section 5.1. The header protection key is not updated. Section 5.1. The header protection key is not updated.
For example, to update write keys with TLS 1.3, HKDF-Expand-Label is For example, to update write keys with TLS 1.3, HKDF-Expand-Label is
used as: used as:
secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku", secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku",
skipping to change at page 31, line 50 skipping to change at page 33, line 29
protection keys in place of discarded keys when key updates are not protection keys in place of discarded keys when key updates are not
yet permitted. Using dummy keys will generate no variation in the yet permitted. Using dummy keys will generate no variation in the
timing signal produced by attempting to remove packet protection, and timing signal produced by attempting to remove packet protection, and
results in all packets with an invalid Key Phase bit being rejected. results in all packets with an invalid Key Phase bit being rejected.
The process of creating new packet protection keys for receiving The process of creating new packet protection keys for receiving
packets could reveal that a key update has occurred. An endpoint MAY packets could reveal that a key update has occurred. An endpoint MAY
perform this process as part of packet processing, but this creates a perform this process as part of packet processing, but this creates a
timing signal that can be used by an attacker to learn when key timing signal that can be used by an attacker to learn when key
updates happen and thus the value of the Key Phase bit in certain updates happen and thus the value of the Key Phase bit in certain
packets. Endpoints SHOULD instead defer the creation of the next set packets. Endpoints MAY instead defer the creation of the next set of
of receive packet protection keys until some time after a key update receive packet protection keys until some time after a key update
completes, up to three times the PTO; see Section 6.5. completes, up to three times the PTO; see Section 6.5.
Once generated, the next set of packet protection keys SHOULD be Once generated, the next set of packet protection keys SHOULD be
retained, even if the packet that was received was subsequently retained, even if the packet that was received was subsequently
discarded. Packets containing apparent key updates are easy to forge discarded. Packets containing apparent key updates are easy to forge
and - while the process of key update does not require significant and - while the process of key update does not require significant
effort - triggering this process could be used by an attacker for effort - triggering this process could be used by an attacker for
DoS. DoS.
For this reason, endpoints MUST be able to retain two sets of packet For this reason, endpoints MUST be able to retain two sets of packet
skipping to change at page 34, line 29 skipping to change at page 36, line 9
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 provides preliminary cryptographic parameters. The TLS handshake provides preliminary
values for QUIC transport parameters and allows a server to perform values for QUIC transport parameters and allows a server to perform
return routability checks on clients. return routability checks 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) [ALPN] to select an application protocol. Unless
Unless another mechanism is used for agreeing on an application another mechanism is used for agreeing on an application protocol,
protocol, endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST use ALPN for this purpose. When using ALPN, endpoints
endpoints MUST immediately close a connection (see Section 10.3 in 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.9). While [RFC7301] only specifies that servers use this Section 4.9). While [ALPN] 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 protocol MAY restrict the QUIC versions that it can
can operate over. Servers MUST select an application protocol operate over. Servers MUST select an application protocol compatible
compatible with the QUIC version that the client has selected. If with the QUIC version that the client has selected. The server MUST
the server cannot select a compatible combination of application treat the inability to select a compatible application protocol as a
protocol and QUIC version, it MUST abort the connection. A client connection error of type 0x178 (no_application_protocol). Similarly,
MUST abort a connection if the server picks an application protocol a client MUST treat the selection of an incompatible application
incompatible with the protocol version being used. protocol by a server as a connection error of type 0x178.
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.
skipping to change at page 39, line 33 skipping to change at page 41, line 10
The initial secrets use a key that is specific to the negotiated QUIC The initial secrets use a key that is specific to the negotiated QUIC
version. New QUIC versions SHOULD define a new salt value used in version. New QUIC versions SHOULD define a new salt value used in
calculating initial secrets. calculating initial secrets.
10. IANA Considerations 10. IANA Considerations
This document does not create any new IANA registries, but it This document does not create any new IANA registries, but it
registers the values in the following registries: registers the values in the following registries:
o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register * TLS ExtensionType Values Registry [TLS-REGISTRIES] - IANA is to
the quic_transport_parameters extension found in Section 8.2. The register the quic_transport_parameters extension found in
Recommended column is to be marked Yes. The TLS 1.3 Column is to Section 8.2. The Recommended column is to be marked Yes. The TLS
include CH and EE. 1.3 Column is to include CH and EE.
o QUIC Error Codes Registry [QUIC-TRANSPORT] - IANA is to register * QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to
the KEY_UPDATE_ERROR (0xE), as described in Section 6.7. register the KEY_UPDATE_ERROR (0xE), as described in Section 6.7.
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)",
of Standards and Technology report, DOI 10.6028/nist.fips.197, National Institute of Standards
DOI 10.6028/nist.fips.197, November 2001. and Technology report, November 2001,
<https://doi.org/10.6028/nist.fips.197>.
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[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-24 (work and Congestion Control", Work in Progress, Internet-Draft,
in progress), November 2019. draft-ietf-quic-recovery-25, 22 January 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-25>.
[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", Work in Progress,
transport-24 (work in progress), November 2019. Internet-Draft, draft-ietf-quic-transport-25, 22 January
2020, <https://tools.ietf.org/html/draft-ietf-quic-
transport-25>.
[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,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHA] Dang, Q., "Secure Hash Standard", National Institute of [SHA] Dang, Q., "Secure Hash Standard",
Standards and Technology report, DOI 10.6028/nist.fips.180-4, National Institute of
DOI 10.6028/nist.fips.180-4, July 2015. Standards and Technology report, July 2015,
<https://doi.org/10.6028/nist.fips.180-4>.
[TLS-REGISTRIES] [TLS-REGISTRIES]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
[AEBounds] [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated
Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", 8 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>.
[HTTP2-TLS13] [HTTP2-TLS13]
Benjamin, D., "Using TLS 1.3 with HTTP/2", draft-ietf- Benjamin, D., "Using TLS 1.3 with HTTP/2", Work in
httpbis-http2-tls13-03 (work in progress), October 2019. Progress, Internet-Draft, draft-ietf-httpbis-
http2-tls13-03, 17 October 2019, <http://www.ietf.org/
internet-drafts/draft-ietf-httpbis-http2-tls13-03.txt>.
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern [IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269, Cryptography, Second Edition", ISBN 978-1466570269, 6
November 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", DOI 10.1007/978-3-030-26948-7_9, Advances
235-265, DOI 10.1007/978-3-030-26948-7_9, 2019. in Cryptology - CRYPTO 2019 pp. 235-265, 2019,
<https://doi.org/10.1007/978-3-030-26948-7_9>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
QUIC", draft-ietf-quic-http-24 (work in progress), (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
November 2019. quic-http-25, 22 January 2020,
<https://tools.ietf.org/html/draft-ietf-quic-http-25>.
[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>.
11.3. URIs
[1] https://mailarchive.ietf.org/arch/search/?email_list=quic
[2] https://github.com/quicwg
[3] https://github.com/quicwg/base-drafts/labels/-tls
Appendix A. Sample Initial Packet Protection Appendix A. Sample Initial Packet Protection
This section shows examples of packet protection for Initial packets This section shows examples of packet protection for Initial packets
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
skipping to change at page 43, line 22 skipping to change at page 44, line 52
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:
c3ff000017088394c8f03e5157080000449e00000002 c3ff000019088394c8f03e5157080000449e00000002
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 = 535064a4268a0d9d7b1c9d250ae35516 sample = 535064a4268a0d9d7b1c9d250ae35516
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 833b343aaa = 833b343aaa
header[0] ^= mask[0] & 0x0f header[0] ^= mask[0] & 0x0f
= c0 = c0
header[17..20] ^= mask[1..4] header[18..21] ^= mask[1..4]
= 3b343aa8 = 3b343aa8
header = c0ff000017088394c8f03e5157080000449e3b343aa8 header = c0ff000019088394c8f03e5157080000449e3b343aa8
The resulting protected packet is: The resulting protected packet is:
c0ff000017088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c c0ff000019088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c
9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752 9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752
4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec 4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec
b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f
e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d
12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6 12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6
11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50 11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50
1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008 1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008
0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f 0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f
cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724 cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724
87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d 87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d
skipping to change at page 44, line 42 skipping to change at page 46, line 42
93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9 93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9
44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14 44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14
a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5 a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5
b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6 b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6
6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e 6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e
c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e
eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f
cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da
acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc
13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d 13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d
c9be6c7803567321829dd85853396269 aebe13f98ec51170a4aad0a8324bb768
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:
c1ff0000170008f067a5502a4262b50040740001 c1ff0000190008f067a5502a4262b50040740001
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 = 7002596f99ae67abf65a5852f54f58c3 sample = 7002596f99ae67abf65a5852f54f58c3
mask = 38168a0c25 mask = 38168a0c25
header = c9ff0000170008f067a5502a4262b5004074168b header = c9ff0000190008f067a5502a4262b5004074168b
The final protected packet is then: The final protected packet is then:
c9ff0000170008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a c9ff0000190008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493 5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3 537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b9cf9bb6d091ddfc8b32d cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b99c8ae5833225cb51855
432348a2c413 20d61e68cf5f
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-23 B.1. Since draft-ietf-quic-tls-24
o Key update text update (#3050): * Rewrite key updates (#3050)
* Recommend constant-time key replacement (#2792) - Allow but don't recommend deferring key updates (#2792, #3263)
* Provide explicit labels for key update key derivation (#3054) - More completely define received behavior (#2791)
o Allow first Initial from a client to span multiple packets (#2928, - Define the label used with HKDF-Expand-Label (#3054)
B.2. Since draft-ietf-quic-tls-23
* Key update text update (#3050):
- Recommend constant-time key replacement (#2792)
- Provide explicit labels for key update key derivation (#3054)
* Allow first Initial from a client to span multiple packets (#2928,
#3045) #3045)
o PING can be sent at any encryption level (#3034, #3035) * PING can be sent at any encryption level (#3034, #3035)
B.2. Since draft-ietf-quic-tls-22 B.3. Since draft-ietf-quic-tls-22
o Update the salt used for Initial secrets (#2887, #2980) * Update the salt used for Initial secrets (#2887, #2980)
B.3. Since draft-ietf-quic-tls-21 B.4. Since draft-ietf-quic-tls-21
o No changes * No changes
B.4. Since draft-ietf-quic-tls-20 B.5. Since draft-ietf-quic-tls-20
o Mandate the use of the QUIC transport parameters extension (#2528, * Mandate the use of the QUIC transport parameters extension (#2528,
#2560) #2560)
o 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)
B.5. Since draft-ietf-quic-tls-18 B.6. Since draft-ietf-quic-tls-18
o Increased the set of permissible frames in 0-RTT (#2344, #2355) * Increased the set of permissible frames in 0-RTT (#2344, #2355)
o Transport parameter extension is mandatory (#2528, #2560) * Transport parameter extension is mandatory (#2528, #2560)
B.6. Since draft-ietf-quic-tls-17 B.7. Since draft-ietf-quic-tls-17
o 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)
o Use of ALPN or equivalent is mandatory (#2263, #2284) * Use of ALPN or equivalent is mandatory (#2263, #2284)
B.7. Since draft-ietf-quic-tls-14 B.8. Since draft-ietf-quic-tls-14
o Update the salt used for Initial secrets (#1970) * Update the salt used for Initial secrets (#1970)
o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) * Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
o 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,
#2006) #2006)
o 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)
* Change the labels for calculation of QUIC keys (#1845, #1971, - Clarify that the TLS KDF is used with TLS (#1997)
- Change the labels for calculation of QUIC keys (#1845, #1971,
#1991) #1991)
o Initial keys are discarded once Handshake keys are available * Initial keys are discarded once Handshake keys are available
(#1951, #2045) (#1951, #2045)
B.8. Since draft-ietf-quic-tls-13 B.9. Since draft-ietf-quic-tls-13
o Updated to TLS 1.3 final (#1660) * Updated to TLS 1.3 final (#1660)
B.9. Since draft-ietf-quic-tls-12 B.10. Since draft-ietf-quic-tls-12
o 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)
o Changed codepoint of TLS extension (#1395, #1402) * Changed codepoint of TLS extension (#1395, #1402)
B.10. Since draft-ietf-quic-tls-11 B.11. Since draft-ietf-quic-tls-11
o Encrypted packet numbers. * Encrypted packet numbers.
B.11. Since draft-ietf-quic-tls-10 B.12. Since draft-ietf-quic-tls-10
o No significant changes. * No significant changes.
B.12. Since draft-ietf-quic-tls-09 B.13. Since draft-ietf-quic-tls-09
o 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)
B.13. Since draft-ietf-quic-tls-08 B.14. Since draft-ietf-quic-tls-08
o Specify value for max_early_data_size to enable 0-RTT (#942) * Specify value for max_early_data_size to enable 0-RTT (#942)
o Update key derivation function (#1003, #1004) * Update key derivation function (#1003, #1004)
B.14. Since draft-ietf-quic-tls-07 B.15. Since draft-ietf-quic-tls-07
o Handshake errors can be reported with CONNECTION_CLOSE (#608, * Handshake errors can be reported with CONNECTION_CLOSE (#608,
#891) #891)
B.15. Since draft-ietf-quic-tls-05 B.16. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
B.16. Since draft-ietf-quic-tls-04 B.17. Since draft-ietf-quic-tls-04
o 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)
B.17. Since draft-ietf-quic-tls-03 B.18. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
B.18. Since draft-ietf-quic-tls-02 B.19. Since draft-ietf-quic-tls-02
o Updates to match changes in transport draft * Updates to match changes in transport draft
B.19. Since draft-ietf-quic-tls-01 B.20. Since draft-ietf-quic-tls-01
o Use TLS alerts to signal TLS errors (#272, #374) * Use TLS alerts to signal TLS errors (#272, #374)
o Require ClientHello to fit in a single packet (#338) * Require ClientHello to fit in a single packet (#338)
o 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)
o The QUIC header is included as AEAD Associated Data (#226, #243, * The QUIC header is included as AEAD Associated Data (#226, #243,
#302) #302)
o Add interface necessary for client address validation (#275) * Add interface necessary for client address validation (#275)
o Define peer authentication (#140) * Define peer authentication (#140)
o Require at least TLS 1.3 (#138) * Require at least TLS 1.3 (#138)
o Define transport parameters as a TLS extension (#122) * Define transport parameters as a TLS extension (#122)
o Define handling for protected packets before the handshake * Define handling for protected packets before the handshake
completes (#39) completes (#39)
o Decouple QUIC version and ALPN (#12) * Decouple QUIC version and ALPN (#12)
B.20. Since draft-ietf-quic-tls-00
o Changed bit used to signal key phase
o Updated key phase markings during the handshake B.21. Since draft-ietf-quic-tls-00
* Changed bit used to signal key phase
o Added TLS interface requirements section * Updated key phase markings during the handshake
o Moved to use of TLS exporters for key derivation
o Moved TLS error code definitions into this document * Added TLS interface requirements section
B.21. Since draft-thomson-quic-tls-01 * Moved to use of TLS exporters for key derivation
o Adopted as base for draft-ietf-quic-tls * Moved TLS error code definitions into this document
o Updated authors/editors list B.22. Since draft-thomson-quic-tls-01
o Added status note * Adopted as base for draft-ietf-quic-tls
Acknowledgments * Updated authors/editors list
This document has benefited from input from Dragana Damjanovic, * Added status note
Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric
Rescorla, Ian Swett, and many others.
Contributors Contributors
Ryan Hamilton was originally an author of this specification. The IETF QUIC Working Group received an enormous amount of support
from many people. The following people provided substantive
contributions to this document: Adam Langley, Alessandro Ghedini,
Christian Huitema, Christopher Wood, David Schinazi, Dragana
Damjanovic, Eric Rescorla, Ian Swett, Jana Iyengar, 奥 一穂 (Kazuho
Oku), Marten Seemann, Martin Duke, Mike Bishop, Mikkel Fahnøe
Jørgensen, Nick Banks, Nick Harper, Roberto Peon, Rui Paulo, Ryan
Hamilton, and Victor Vasiliev.
Authors' Addresses Authors' Addresses
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
Email: mt@lowentropy.net Email: mt@lowentropy.net
Sean Turner (editor) Sean Turner (editor)
sn3rd sn3rd
 End of changes. 155 change blocks. 
286 lines changed or deleted 365 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/