draft-ietf-quic-tls-27.txt   draft-ietf-quic-tls-28.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: 24 August 2020 sn3rd Expires: 21 November 2020 sn3rd
21 February 2020 20 May 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-27 draft-ietf-quic-tls-28
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 (mailto:quic@ietf.org)), which is
https://mailarchive.ietf.org/arch/search/?email_list=quic archived at https://mailarchive.ietf.org/arch/
(https://mailarchive.ietf.org/arch/search/?email_list=quic). 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;
(https://github.com/quicwg); source code and issues list for this source code and issues list for this draft can be found at
draft can be found at https://github.com/quicwg/base-drafts/labels/- https://github.com/quicwg/base-drafts/labels/-tls.
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 24 August 2020. This Internet-Draft will expire on 21 November 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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
4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10 4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 11
4.1.3. Sending and Receiving Handshake Messages . . . . . . 10 4.1.3. Sending and Receiving Handshake Messages . . . . . . 11
4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12 4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 13
4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13 4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 14
4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15
4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15 4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 16
4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 16 4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 17
4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16 4.6. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 17
4.7. Validating 0-RTT Configuration . . . . . . . . . . . . . 17 4.7. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 18
4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 17 4.8. Validating 0-RTT Configuration . . . . . . . . . . . . . 18
4.9. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 18 4.9. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 19
4.10. Discarding Unused Keys . . . . . . . . . . . . . . . . . 18 4.10. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 19
4.10.1. Discarding Initial Keys . . . . . . . . . . . . . . 19 4.11. Discarding Unused Keys . . . . . . . . . . . . . . . . . 19
4.10.2. Discarding Handshake Keys . . . . . . . . . . . . . 19 4.11.1. Discarding Initial Keys . . . . . . . . . . . . . . 20
4.10.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 19 4.11.2. Discarding Handshake Keys . . . . . . . . . . . . . 20
5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 20 4.11.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 20
5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 20 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 20 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 21
5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 21
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 23 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.1. Header Protection Application . . . . . . . . . . . . 23 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 24
5.4.2. Header Protection Sample . . . . . . . . . . . . . . 25 5.4.1. Header Protection Application . . . . . . . . . . . . 24
5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 26 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 26
5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 26 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 28
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 27 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 28
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 27 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 28
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 28 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 29
5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 29 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 29
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 30
6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 31
6.2. Responding to a Key Update . . . . . . . . . . . . . . . 32 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3. Timing of Receive Key Generation . . . . . . . . . . . . 33 6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 33
6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 33 6.2. Responding to a Key Update . . . . . . . . . . . . . . . 34
6.5. Receiving with Different Keys . . . . . . . . . . . . . . 34 6.3. Timing of Receive Key Generation . . . . . . . . . . . . 34
6.6. Key Update Frequency . . . . . . . . . . . . . . . . . . 35 6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 35
6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 35 6.5. Receiving with Different Keys . . . . . . . . . . . . . . 35
7. Security of Initial Messages . . . . . . . . . . . . . . . . 35 6.6. Key Update Frequency . . . . . . . . . . . . . . . . . . 36
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 35 6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 36
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 36 7. Security of Initial Messages . . . . . . . . . . . . . . . . 37
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 36 8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 37
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 37 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 38
9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 37 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 38
9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 38 8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 39
9.3. Header Protection Analysis . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
9.4. Header Protection Timing Side-Channels . . . . . . . . . 39 9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 39
9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 40 9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 9.4. Header Protection Analysis . . . . . . . . . . . . . . . 41
11.1. Normative References . . . . . . . . . . . . . . . . . . 41 9.5. Header Protection Timing Side-Channels . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . 42 9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 42
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 44 11.1. Normative References . . . . . . . . . . . . . . . . . . 43
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 46 11.2. Informative References . . . . . . . . . . . . . . . . . 44
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 45
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.1. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 47 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 46
B.2. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 47 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 48
B.3. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 48 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.4. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 48 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 49
B.5. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 48 B.1. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 49
B.6. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 48 B.2. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 49
B.7. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 48 B.3. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 50
B.8. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 48 B.4. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 50
B.9. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 48 B.5. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 50
B.10. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 49 B.6. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 50
B.11. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 49 B.7. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 50
B.12. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 49 B.8. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 50
B.13. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 50 B.9. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 51
B.14. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 50 B.10. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 51
B.15. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 50 B.11. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 51
B.16. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 50 B.12. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 51
B.17. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 50 B.13. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 51
B.18. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 50 B.14. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 52
B.19. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 50 B.15. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 52
B.20. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 50 B.16. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 52
B.21. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 50 B.17. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 52
B.22. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 50 B.18. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 52
B.23. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 51 B.19. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 52
B.24. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 51 B.20. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 52
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 52 B.21. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 B.22. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 53
B.23. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 53
B.24. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 53
B.25. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 53
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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,
the client can often send application data immediately, that is, the client can often send application data immediately, that is,
using a zero round trip setup. using a zero round trip setup.
This document describes how TLS acts as a security component of QUIC. This document describes how TLS acts as a security component of QUIC.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terminology established in [QUIC-TRANSPORT]. This document uses the terminology established in [QUIC-TRANSPORT].
For brevity, the acronym TLS is used to refer to TLS 1.3, though a For brevity, the acronym TLS is used to refer to TLS 1.3, though a
newer version could be used (see Section 4.2). newer version could be used (see Section 4.2).
2.1. TLS Overview 2.1. TLS Overview
TLS provides two endpoints with a way to establish a means of TLS provides two endpoints with a way to establish a means of
skipping to change at page 6, line 8 skipping to change at page 6, line 12
responds after receiving the first handshake message from the responds after receiving the first handshake message from the
client. client.
* A 0-RTT handshake in which the client uses information it has * A 0-RTT handshake in which the client uses information it has
previously learned about the server to send Application Data previously learned about the server to send Application Data
immediately. This Application Data can be replayed by an attacker immediately. This Application Data can be replayed by an attacker
so it MUST NOT carry a self-contained trigger for any non- so 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.
not used in QUIC (see Section 8.3). Likewise, neither
ChangeCipherSpec nor KeyUpdate messages are used by QUIC;
ChangeCipherSpec is redundant in TLS 1.3 and QUIC has defined its own
key update mechanism Section 6.
Client Server Client Server
ClientHello ClientHello
(0-RTT Application Data) --------> (0-RTT Application Data) -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
{Finished} {Finished}
<-------- [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
Figure 2 omits the EndOfEarlyData message, which is not used in QUIC;
see Section 8.3. Likewise, neither ChangeCipherSpec nor KeyUpdate
messages are used by QUIC. ChangeCipherSpec is redundant in TLS 1.3;
see Section 8.4. QUIC has its own key update mechanism; see
Section 6.
Data is protected using a number of encryption levels: Data is protected using a number of encryption levels:
* Initial Keys * Initial Keys
* Early Data (0-RTT) Keys * Early Data (0-RTT) Keys
* Handshake Keys * Handshake Keys
* Application Data (1-RTT) Keys * Application Data (1-RTT) Keys
skipping to change at page 8, line 43 skipping to change at page 9, line 7
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
currently using. If QUIC needs to retransmit that data, it MUST use currently using. If QUIC needs to retransmit that data, it MUST use
the same keys even if TLS has already updated to newer keys. the same keys even if TLS has already updated to newer keys.
One important difference between TLS records (used with TCP) and QUIC One important difference between TLS records (used with TCP) and QUIC
CRYPTO frames is that in QUIC multiple frames may appear in the same CRYPTO frames is that in QUIC multiple frames may appear in the same
QUIC packet as long as they are associated with the same encryption QUIC packet as long as they are associated with the same packet
level. For instance, an implementation might bundle a Handshake number space. For instance, an endpoint can bundle a Handshake
message and an ACK for some Handshake data into the same packet. message and an ACK for some Handshake data into the same packet.
Some frames are prohibited in different encryption levels, others Some frames are prohibited in different packet number spaces. The
cannot be sent. The rules here generalize those of TLS, in that rules here generalize those of TLS, in that frames associated with
frames associated with establishing the connection can usually appear establishing the connection can usually appear in packets in any
at any encryption level, whereas those associated with transferring packet number space, whereas those associated with transferring data
data can only appear in the 0-RTT and 1-RTT encryption levels: can only appear in the application data packet number space:
* PADDING and PING frames MAY appear in packets of any encryption
level.
* CRYPTO frames and CONNECTION_CLOSE frames signaling errors at the * PADDING, PING, and CRYPTO frames MAY appear in any packet number
QUIC layer (type 0x1c) MAY appear in packets of any encryption space.
level except 0-RTT.
* CONNECTION_CLOSE frames signaling application errors (type 0x1d) * CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
MUST only be sent in packets at the 1-RTT encryption level. 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE
frames signaling application errors (type 0x1d) MUST only appear
in the application data packet number space.
* ACK frames MAY appear in packets of any encryption level other * ACK frames MAY appear in any packet number space, but can only
than 0-RTT, but can only acknowledge packets which appeared in acknowledge packets which appeared in that packet number space.
that packet number space. However, as noted below, 0-RTT packets cannot contain ACK frames.
* All other frame types MUST only be sent in the 0-RTT and 1-RTT * All other frame types MUST only be sent in the application data
levels. packet number space.
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, HANDSHAKE_DONE, NEW_TOKEN, packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
PATH_RESPONSE, and RETIRE_CONNECTION_ID. PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
of these frames in 0-RTT packets as a connection error of type
PROTOCOL_VIOLATION.
Because packets could be reordered on the wire, QUIC uses the packet Because packets could be reordered on the wire, QUIC uses the packet
type to indicate which level a given packet was encrypted under, as type to indicate which keys were used to protect a given packet, as
shown in Table 1. When multiple packets of different encryption shown in Table 1. When packets of different types need to be sent,
levels need to be sent, endpoints SHOULD use coalesced packets to endpoints SHOULD use coalesced packets to send them in the same UDP
send them in the same UDP datagram. datagram.
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
| Packet Type | Encryption Level | PN Space | | Packet Type | Encryption Keys | PN Space |
+=====================+==================+===========+ +=====================+=================+==================+
| Initial | Initial secrets | Initial | | Initial | Initial secrets | Initial |
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
| 0-RTT Protected | 0-RTT | 0/1-RTT | | 0-RTT Protected | 0-RTT | Application data |
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
| Handshake | Handshake | Handshake | | Handshake | Handshake | Handshake |
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
| Retry | N/A | N/A | | Retry | Retry | 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 | Application data |
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
Table 1: Encryption Levels by Packet Type Table 1: Encryption Keys 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:
* Sending and receiving handshake messages * Sending and receiving handshake messages
skipping to change at page 11, line 14 skipping to change at page 11, line 34
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.
A QUIC client starts TLS by requesting TLS handshake bytes from TLS. A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
The client acquires handshake bytes before sending its first packet. The client acquires handshake bytes before sending its first packet.
A QUIC server starts the process by providing TLS with the client's A QUIC server starts the process by providing TLS with the client's
handshake bytes. handshake bytes.
At any time, the TLS stack at an endpoint will have a current sending At any time, the TLS stack at an endpoint will have a current sending
encryption level and receiving encryption level. Each encryption encryption level and receiving encryption level. Encryption levels
level is associated with a different flow of bytes, which is reliably determine the packet type and keys that are used for protecting data.
transmitted to the peer in CRYPTO frames. When TLS provides
handshake bytes to be sent, they are appended to the current flow and Each encryption level is associated with a different sequence of
any packet that includes the CRYPTO frame is protected using keys bytes, which is reliably transmitted to the peer in CRYPTO frames.
from the corresponding encryption level. When TLS provides handshake bytes to be sent, they are appended to
the current flow. Any packet that includes the CRYPTO frame is
protected using keys from the corresponding encryption level. Four
encryption levels are used, producing keys for Initial, 0-RTT,
Handshake, and 1-RTT packets. CRYPTO frames are carried in just
three of these levels, omitting the 0-RTT level. These four levels
correspond to three packet number spaces: Initial and Handshake
encrypted packets use their own separate spaces; 0-RTT and 1-RTT
packets use the application data packet number space.
QUIC takes the unprotected content of TLS handshake records as the QUIC takes the unprotected content of TLS handshake records as the
content of CRYPTO frames. TLS record protection is not used by QUIC. content of CRYPTO frames. TLS record protection is not used by QUIC.
QUIC assembles CRYPTO frames into QUIC packets, which are protected QUIC assembles CRYPTO frames into QUIC packets, which are protected
using QUIC packet protection. using QUIC packet protection.
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.10. TLS application data and other message
cannot be carried by QUIC at any encryption level and is an error if types cannot be carried by QUIC at any encryption level and is an
they are received from the TLS stack. error if 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:
* 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.
* 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.
* 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.
skipping to change at page 16, line 24 skipping to change at page 17, line 5
A server MUST NOT use post-handshake client authentication (as A server MUST NOT use post-handshake client authentication (as
defined in Section 4.6.2 of [TLS13]), because the multiplexing defined in Section 4.6.2 of [TLS13]), because the multiplexing
offered by QUIC prevents clients from correlating the certificate offered by QUIC prevents clients from correlating the certificate
request with the application-level event that triggered it (see request with the application-level event that triggered it (see
[HTTP2-TLS13]). More specifically, servers MUST NOT send post- [HTTP2-TLS13]). More specifically, servers MUST NOT send post-
handshake TLS CertificateRequest messages and clients MUST treat handshake TLS CertificateRequest messages and clients MUST treat
receipt of such messages as a connection error of type receipt of such messages as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
4.5. Enabling 0-RTT 4.5. Session Resumption
QUIC can use the session resumption feature of TLS 1.3. It does this
by carrying NewSessionTicket messages in CRYPTO frames after the
handshake is complete. Session resumption is the basis of 0-RTT, but
can be used without also enabling 0-RTT.
Endpoints that use session resumption might need to remember some
information about the current connection when creating a resumed
connection. TLS requires that some information be retained; see
Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state
being retained when resuming a connection, unless 0-RTT is also used;
see Section 4.6 and Section 7.3.1 of [QUIC-TRANSPORT]. Application
protocols could depend on state that is retained between resumed
connections.
Clients can store any state required for resumption along with the
session ticket. Servers can use the session ticket to help carry
state.
Session resumption allows servers to link activity on the original
connection with the resumed connection, which might be a privacy
issue for clients. Clients can choose not to enable resumption to
avoid creating this correlation. Client SHOULD NOT reuse tickets as
that allows entities other than the server to correlate connections;
see Section C.4 of [TLS13].
4.6. Enabling 0-RTT
To communicate their willingness to process 0-RTT data, servers send To communicate their willingness to process 0-RTT data, servers send
a NewSessionTicket message that contains the "early_data" extension a NewSessionTicket message that contains the "early_data" extension
with a max_early_data_size of 0xffffffff; the amount of data which with a 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" the client can send in 0-RTT is controlled by the "initial_max_data"
transport parameter supplied by the server. Servers MUST NOT send transport parameter supplied by the server. Servers MUST NOT send
the "early_data" extension with a max_early_data_size set to any the "early_data" extension with a max_early_data_size set to any
value other than 0xffffffff. A client MUST treat receipt of a value other than 0xffffffff. A client MUST treat receipt of a
NewSessionTicket that contains an "early_data" extension with any NewSessionTicket that contains an "early_data" extension with any
other value as a connection error of type PROTOCOL_VIOLATION. other value as a connection error of type PROTOCOL_VIOLATION.
A client that wishes to send 0-RTT packets uses the "early_data" A client that wishes to send 0-RTT packets uses the "early_data"
extension in the ClientHello message of a subsequent handshake (see extension in the ClientHello message of a subsequent handshake (see
Section 4.2.10 of [TLS13]). It then sends the application data in Section 4.2.10 of [TLS13]). It then sends the application data in
0-RTT packets. 0-RTT packets.
4.6. Accepting and Rejecting 0-RTT 4.7. Accepting and Rejecting 0-RTT
A server accepts 0-RTT by sending an early_data extension in the A server accepts 0-RTT by sending an early_data extension in the
EncryptedExtensions (see Section 4.2.10 of [TLS13]). The server then EncryptedExtensions (see Section 4.2.10 of [TLS13]). The server then
processes and acknowledges the 0-RTT packets that it receives. processes and acknowledges the 0-RTT packets that it receives.
A server rejects 0-RTT by sending the EncryptedExtensions without an A server rejects 0-RTT by sending the EncryptedExtensions without an
early_data extension. A server will always reject 0-RTT if it sends early_data extension. A server will always reject 0-RTT if it sends
a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT
process any 0-RTT packets, even if it could. When 0-RTT was process any 0-RTT packets, even if it could. When 0-RTT was
rejected, a client SHOULD treat receipt of an acknowledgement for a rejected, a client SHOULD treat receipt of an acknowledgement for a
skipping to change at page 17, line 17 skipping to change at page 18, line 29
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.
4.7. Validating 0-RTT Configuration 4.8. Validating 0-RTT Configuration
When a server receives a ClientHello with the "early_data" extension, When a server receives a ClientHello with the "early_data" extension,
it has to decide whether to accept or reject early data from the it has to decide whether to accept or reject early data from the
client. Some of this decision is made by the TLS stack (e.g., client. Some of this decision is made by the TLS stack (e.g.,
checking that the cipher suite being resumed was included in the checking that the cipher suite being resumed was included in the
ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack
has no reason to reject early data, the QUIC stack or the application has no reason to reject early data, the QUIC stack or the application
protocol using QUIC might reject early data because the configuration protocol using QUIC might reject early data because the configuration
of the transport or application associated with the resumed session of the transport or application associated with the resumed session
is not compatible with the server's current configuration. is not compatible with the server's current configuration.
skipping to change at page 17, line 40 skipping to change at page 19, line 5
0-RTT session ticket. One common way to implement this is using 0-RTT session ticket. One common way to implement this is using
stateless session tickets and storing this state in the session stateless session tickets and storing this state in the session
ticket. Application protocols that use QUIC might have similar ticket. Application protocols that use QUIC might have similar
requirements regarding associating or storing state. This associated requirements regarding associating or storing state. This associated
state is used for deciding whether early data must be rejected. For state is used for deciding whether early data must be rejected. For
example, HTTP/3 ([QUIC-HTTP]) settings determine how early data from example, HTTP/3 ([QUIC-HTTP]) settings determine how early data from
the client is interpreted. Other applications using QUIC could have the client is interpreted. Other applications using QUIC could have
different requirements for determining whether to accept or reject different requirements for determining whether to accept or reject
early data. early data.
4.8. HelloRetryRequest 4.9. HelloRetryRequest
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
[TLS13]) can be used to correct a client's incorrect KeyShare [TLS13]) can be used to correct a client's incorrect KeyShare
extension as well as for a stateless round-trip check. From the extension as well as for a stateless round-trip check. From the
perspective of QUIC, this just looks like additional messages carried perspective of QUIC, this just looks like additional messages carried
in the Initial encryption level. Although it is in principle in Initial packets. Although it is in principle possible to use this
possible to use this feature for address verification in QUIC, QUIC feature for address verification in QUIC, QUIC implementations SHOULD
implementations SHOULD instead use the Retry feature (see Section 8.1 instead use the Retry feature (see Section 8.1 of [QUIC-TRANSPORT]).
of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key HelloRetryRequest is still used to request key shares.
shares.
4.9. TLS Errors 4.10. TLS Errors
If TLS experiences an error, it generates an appropriate alert as If TLS experiences an error, it generates an appropriate alert as
defined in Section 6 of [TLS13]. defined in Section 6 of [TLS13].
A TLS alert is turned into a QUIC connection error by converting the A TLS alert is converted into a QUIC connection error. The alert
one-byte alert description into a QUIC error code. The alert
description is added to 0x100 to produce a QUIC error code from the description is added to 0x100 to produce a QUIC error code from the
range reserved for CRYPTO_ERROR. The resulting value is sent in a range reserved for CRYPTO_ERROR. The resulting value is sent in a
QUIC CONNECTION_CLOSE frame. QUIC CONNECTION_CLOSE frame of type 0x1c.
The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
generate alerts at the "warning" level. generate alerts at the "warning" level.
4.10. Discarding Unused Keys QUIC permits the use of a generic code in place of a specific error
code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this
includes replacing any alert with a generic alert, such as
handshake_failure (0x128 in QUIC). Endpoints MAY use a generic error
code to avoid possibly exposing confidential information.
4.11. Discarding Unused Keys
After QUIC moves to a new encryption level, packet protection keys After QUIC moves to a new encryption level, packet protection keys
for previous encryption levels can be discarded. This occurs several for previous encryption levels can be discarded. This occurs several
times during the handshake, as well as when keys are updated; see times during the handshake, as well as when keys are updated; see
Section 6. Section 6.
Packet protection keys are not discarded immediately when new keys Packet protection keys are not discarded immediately when new keys
are available. If packets from a lower encryption level contain are available. If packets from a lower encryption level contain
CRYPTO frames, frames that retransmit that data MUST be sent at the CRYPTO frames, frames that retransmit that data MUST be sent at the
same encryption level. Similarly, an endpoint generates same encryption level. Similarly, an endpoint generates
skipping to change at page 19, line 5 skipping to change at page 20, line 18
have been acknowledged by its peer. However, this does not guarantee have been acknowledged by its peer. However, this does not guarantee
that no further packets will need to be received or sent at that that no further packets will need to be received or sent at that
encryption level because a peer might not have received all the encryption level because a peer might not have received all the
acknowledgements necessary to reach the same state. acknowledgements necessary to reach the same state.
Though an endpoint might retain older keys, new data MUST be sent at Though an endpoint might retain older keys, new data MUST be sent at
the highest currently-available encryption level. Only ACK frames the highest currently-available encryption level. Only ACK frames
and retransmissions of data in CRYPTO frames are sent at a previous and retransmissions of data in CRYPTO frames are sent at a previous
encryption level. These packets MAY also include PADDING frames. encryption level. These packets MAY also include PADDING frames.
4.10.1. Discarding Initial Keys 4.11.1. Discarding Initial Keys
Packets protected with Initial secrets (Section 5.2) are not Packets protected with Initial secrets (Section 5.2) are not
authenticated, meaning that an attacker could spoof packets with the authenticated, meaning that an attacker could spoof packets with the
intent to disrupt a connection. To limit these attacks, Initial intent to disrupt a connection. To limit these attacks, Initial
packet protection keys can be discarded more aggressively than other packet protection keys can be discarded more aggressively than other
keys. keys.
The successful use of Handshake packets indicates that no more The successful use of Handshake packets indicates that no more
Initial packets need to be exchanged, as these keys can only be Initial packets need to be exchanged, as these keys can only be
produced after receiving all CRYPTO frames from Initial packets. produced after receiving all CRYPTO frames from Initial packets.
Thus, a client MUST discard Initial keys when it first sends a Thus, a client MUST discard Initial keys when it first sends a
Handshake packet and a server MUST discard Initial keys when it first Handshake packet and a server MUST discard Initial keys when it first
successfully processes a Handshake packet. Endpoints MUST NOT send successfully processes a Handshake packet. Endpoints MUST NOT send
Initial packets after this point. Initial packets after this point.
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.11.2. Discarding Handshake Keys
An endpoint MUST discard its handshake keys when the TLS handshake is An endpoint MUST discard its handshake keys when the TLS handshake is
confirmed (Section 4.1.2). The server MUST send a HANDSHAKE_DONE confirmed (Section 4.1.2). The server MUST send a HANDSHAKE_DONE
frame as soon as it completes the handshake. frame as soon as it completes the handshake.
4.10.3. Discarding 0-RTT Keys 4.11.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.
Additionally, a server MAY discard 0-RTT keys as soon as it receives Additionally, a server MAY discard 0-RTT keys as soon as it receives
a 1-RTT packet. However, due to packet reordering, a 0-RTT packet a 1-RTT packet. However, due to packet reordering, a 0-RTT packet
skipping to change at page 20, line 32 skipping to change at page 21, line 43
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.6.
The KDF used for initial secrets is always the HKDF-Expand-Label The KDF used for initial secrets is always the HKDF-Expand-Label
function from TLS 1.3 (see Section 5.2). function from TLS 1.3 (see Section 5.2).
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 Initial packet. Destination Connection ID field from the client's Initial packet.
Specifically: Specifically:
skipping to change at page 24, line 20 skipping to change at page 25, line 24
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 an example long header packet (Initial) and a short
with an E. Figure 7 also shows the sampled fields. header packet. Figure 7 shows the fields in each header that are
covered by header protection and the portion of the protected packet
Long Header: payload that is sampled.
+-+-+-+-+-+-+-+-+
|1|1|T T|E E E E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version -> Length Fields ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Short Header: Initial Packet {
+-+-+-+-+-+-+-+-+ Header Form (1) = 1,
|0|1|S|E E E E E| Fixed Bit (1) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Long Packet Type (2) = 0,
| Destination Connection ID (0/32..144) ... Reserved Bits (2), # Protected
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Number Length (2), # Protected
Version (32),
DCID Len (8),
Destination Connection ID (0..160),
SCID Len (8),
Source Connection ID (0..160),
Token Length (i),
Token (..),
Packet Number (8..32), # Protected
Protected Payload (0..24), # Skipped Part
Protected Payload (128), # Sampled Part
Protected Payload (..) # Remainder
}
Common Fields: Short Header Packet {
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header Form (1) = 0,
|E E E E E E E E E Packet Number (8/16/24/32) E E E E E E E E... Fixed Bit (1) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Spin Bit (1),
| [Protected Payload (8/16/24)] ... Reserved Bits (2), # Protected
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Phase (1), # Protected
| Sampled part of Protected Payload (128) ... Packet Number Length (2), # Protected
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Connection ID (0..160),
| Protected Payload Remainder (*) ... Packet Number (8..32), # Protected
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protected Payload (0..24), # Skipped Part
Protected Payload (128), # Sampled Part
Protected Payload (..), # Remainder
}
Figure 7: Header Protection and Ciphertext Sample Figure 7: Header Protection and Ciphertext Sample
Before a TLS ciphersuite can be used with QUIC, a header protection Before a TLS ciphersuite can be used with QUIC, a header protection
algorithm MUST be specified for the AEAD used with that ciphersuite. algorithm MUST be specified for the AEAD used with that ciphersuite.
This document defines algorithms for AEAD_AES_128_GCM, This document defines algorithms for AEAD_AES_128_GCM,
AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in
[AEAD]), and AEAD_CHACHA20_POLY1305 [CHACHA]. Prior to TLS selecting [AEAD]), and AEAD_CHACHA20_POLY1305 [CHACHA]. Prior to TLS selecting
a ciphersuite, AES header protection is used (Section 5.4.3), a ciphersuite, AES header protection is used (Section 5.4.3),
matching the AEAD_AES_128_GCM packet protection. matching the AEAD_AES_128_GCM packet protection.
skipping to change at page 27, line 22 skipping to change at page 29, line 12
appears to trigger a key update, but cannot be unprotected appears to trigger a key update, but cannot be unprotected
successfully MUST be discarded. successfully MUST be discarded.
Failure to unprotect a packet does not necessarily indicate the Failure to unprotect a packet does not necessarily indicate the
existence of a protocol error in a peer or an attack. The truncated existence of a protocol error in a peer or an attack. The truncated
packet number encoding used in QUIC can cause packet numbers to be packet number encoding used in QUIC can cause packet numbers to be
decoded incorrectly if they are delayed significantly. decoded incorrectly if they are delayed significantly.
5.6. Use of 0-RTT Keys 5.6. Use of 0-RTT Keys
If 0-RTT keys are available (see Section 4.5), the lack of replay If 0-RTT keys are available (see Section 4.6), the lack of replay
protection means that restrictions on their use are necessary to protection means that restrictions on their use are necessary to
avoid replay attacks on the protocol. avoid replay attacks on the protocol.
A client MUST only use 0-RTT keys to protect data that is idempotent. A client MUST only use 0-RTT keys to protect data that is idempotent.
A client MAY wish to apply additional restrictions on what data it A client MAY wish to apply additional restrictions on what data it
sends prior to the completion of the TLS handshake. A client sends prior to the completion of the TLS handshake. A client
otherwise treats 0-RTT keys as equivalent to 1-RTT keys, except that otherwise treats 0-RTT keys as equivalent to 1-RTT keys, except that
it MUST NOT send ACKs with 0-RTT keys. it MUST NOT send ACKs with 0-RTT keys.
A client that receives an indication that its 0-RTT data has been A client that receives an indication that its 0-RTT data has been
skipping to change at page 29, line 31 skipping to change at page 31, line 23
* The plaintext, P, is empty. * The plaintext, P, is empty.
* The associated data, A, is the contents of the Retry Pseudo- * The associated data, A, is the contents of the Retry Pseudo-
Packet, as illustrated in Figure 8: Packet, as illustrated in Figure 8:
The secret key and the nonce are values derived by calling HKDF- The secret key and the nonce are values derived by calling HKDF-
Expand-Label using Expand-Label using
0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as 0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as
the secret, with labels being "quic key" and "quic iv" (Section 5.1). the secret, with labels being "quic key" and "quic iv" (Section 5.1).
0 1 2 3 Retry Pseudo-Packet {
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 Length (8),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Original Destination Connection ID (0..160),
| ODCID Len (8) | Header Form (1) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fixed Bit (1) = 1,
| Original Destination Connection ID (0..160) ... Long Packet Type (2) = 3,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type-Specific Bits (4),
|1|1| 3 | Unused| Version (32),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DCID Len (8),
| Version (32) | Destination Connection ID (0..160),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SCID Len (8),
| DCID Len (8) | Retry Token (..),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Destination Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Retry Pseudo-Packet Figure 8: Retry Pseudo-Packet
The Retry Pseudo-Packet is not sent over the wire. It is computed by The Retry Pseudo-Packet is not sent over the wire. It is computed by
taking the transmitted Retry packet, removing the Retry Integrity Tag taking the transmitted Retry packet, removing the Retry Integrity Tag
and prepending the two following fields: and prepending the two following fields:
ODCID Len: The ODCID Len contains the length in bytes of the ODCID Length: The ODCID Len contains the length in bytes of the
Original Destination Connection ID field that follows it, encoded Original Destination Connection ID field that follows it, encoded
as an 8-bit unsigned integer. as an 8-bit unsigned integer.
Original Destination Connection ID: The Original Destination Original Destination Connection ID: The Original Destination
Connection ID contains the value of the Destination Connection ID Connection ID contains the value of the Destination Connection ID
from the Initial packet that this Retry is in response to. The 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 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 field mitigates an off-path attacker's ability to inject a Retry
packet. packet.
skipping to change at page 30, line 40 skipping to change at page 32, line 24
The Key Phase bit allows a recipient to detect a change in keying The Key Phase bit allows a recipient to detect a change in keying
material without needing to receive the first packet that triggered material without needing to receive the first packet that triggered
the change. An endpoint that notices a changed Key Phase bit updates the change. An endpoint that notices a changed Key Phase bit updates
keys and decrypts the packet that contains the changed value. keys and decrypts the packet that contains the changed value.
This mechanism replaces the TLS KeyUpdate message. Endpoints MUST This mechanism replaces the 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.10).
Figure 9 shows a key update process, where the initial set of keys Figure 9 shows a key update process, where the initial set of keys
used (identified with @M) are replaced by updated keys (identified used (identified with @M) are replaced by updated keys (identified
with @N). The value of the Key Phase bit is indicated in brackets with @N). The value of the Key Phase bit is indicated in brackets
[]. [].
Initiating Peer Responding Peer Initiating Peer Responding Peer
@M [0] QUIC Packets @M [0] QUIC Packets
skipping to change at page 33, line 18 skipping to change at page 34, line 47
packet protected with old keys where any acknowledged packet was packet protected with old keys where any acknowledged packet was
protected with newer keys MAY treat that as a connection error of protected with newer keys MAY treat that as a connection error of
type KEY_UPDATE_ERROR. This indicates that a peer has received and type KEY_UPDATE_ERROR. This indicates that a peer has received and
acknowledged a packet that initiates a key update, but has not acknowledged a packet that initiates a key update, but has not
updated keys in response. updated keys in response.
6.3. Timing of Receive Key Generation 6.3. Timing of Receive Key Generation
Endpoints responding to an apparent key update MUST NOT generate a Endpoints responding to an apparent key update MUST NOT generate a
timing side-channel signal that might indicate that the Key Phase bit timing side-channel signal that might indicate that the Key Phase bit
was invalid (see Section 9.3). Endpoints can use dummy packet was invalid (see Section 9.4). Endpoints can use dummy packet
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
skipping to change at page 34, line 30 skipping to change at page 36, line 8
phase, it can be necessary to distinguish between the two. This can phase, it can be necessary to distinguish between the two. This can
be done using packet numbers. A recovered packet number that is be done using packet numbers. A recovered packet number that is
lower than any packet number from the current key phase uses the lower than any packet number from the current key phase uses the
previous packet protection keys; a recovered packet number that is previous packet protection keys; a recovered packet number that is
higher than any packet number from the current key phase requires the higher than any packet number from the current key phase requires the
use of the next packet protection keys. use of the next packet protection keys.
Some care is necessary to ensure that any process for selecting Some care is necessary to ensure that any process for selecting
between previous, current, and next packet protection keys does not between previous, current, and next packet protection keys does not
expose a timing side channel that might reveal which keys were used expose a timing side channel that might reveal which keys were used
to remove packet protection. See Section 9.4 for more information. to remove packet protection. See Section 9.5 for more information.
Alternatively, endpoints can retain only two sets of packet Alternatively, endpoints can retain only two sets of packet
protection keys, swapping previous for next after enough time has protection keys, swapping previous for next after enough time has
passed to allow for reordering in the network. In this case, the Key passed to allow for reordering in the network. In this case, the Key
Phase bit alone can be used to select keys. Phase bit alone can be used to select keys.
An endpoint MAY allow a period of approximately the Probe Timeout An endpoint MAY allow a period of approximately the Probe Timeout
(PTO; see [QUIC-RECOVERY]) after a key update before it creates the (PTO; see [QUIC-RECOVERY]) after a key update before it creates the
next set of packet protection keys. These updated keys MAY replace next set of packet protection keys. These updated keys MAY replace
the previous keys at that time. With the caveat that PTO is a the previous keys at that time. With the caveat that PTO is a
skipping to change at page 35, line 44 skipping to change at page 37, line 28
modifying the ACK Delay). Note that such a packet could cause a modifying the ACK Delay). Note that such a packet could cause a
legitimate packet to be dropped as a duplicate. Implementations legitimate packet to be dropped as a duplicate. Implementations
SHOULD use caution in relying on any data which is contained in SHOULD use caution in relying on any data which is contained in
Initial packets that is not otherwise authenticated. Initial packets that is not otherwise authenticated.
It is also possible for the attacker to tamper with data that is It is also possible for the attacker to tamper with data that is
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 Adjustments 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 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) [ALPN] to select an application protocol. Unless Negotiation (ALPN) [ALPN] to select an application protocol. Unless
another mechanism is used for agreeing on an application protocol, another mechanism is used for agreeing on an application protocol,
endpoints MUST use ALPN for this purpose. When using ALPN, endpoints endpoints MUST use ALPN for this purpose.
MUST immediately close a connection (see Section 10.3 in
[QUIC-TRANSPORT]) if an application protocol is not negotiated with a When using ALPN, endpoints MUST immediately close a connection (see
no_application_protocol TLS alert (QUIC error code 0x178, see Section 10.3 of [QUIC-TRANSPORT]) with a no_application_protocol TLS
Section 4.9). While [ALPN] only specifies that servers use this alert (QUIC error code 0x178; see Section 4.10) if an application
alert, QUIC clients MUST also use it to terminate a connection when protocol is not negotiated. While [ALPN] only specifies that servers
ALPN negotiation fails. use this alert, QUIC clients MUST use error 0x178 to terminate a
connection when ALPN negotiation fails.
An application protocol MAY restrict the QUIC versions that it can An application protocol MAY restrict the QUIC versions that it can
operate over. Servers MUST select an application protocol compatible operate over. Servers MUST select an application protocol compatible
with the QUIC version that the client has selected. The server MUST with the QUIC version that the client has selected. The server MUST
treat the inability to select a compatible application protocol as a treat the inability to select a compatible application protocol as a
connection error of type 0x178 (no_application_protocol). Similarly, connection error of type 0x178 (no_application_protocol). Similarly,
a client MUST treat the selection of an incompatible application a client MUST treat the selection of an incompatible application
protocol by a server as a connection error of type 0x178. protocol by a server as a connection error of type 0x178.
8.2. QUIC Transport Parameters Extension 8.2. QUIC Transport Parameters Extension
skipping to change at page 36, line 40 skipping to change at page 38, line 22
versions of QUIC might define a different method for negotiating versions of QUIC might define a different method for negotiating
transport configuration. transport configuration.
Including transport parameters in the TLS handshake provides Including transport parameters in the TLS handshake provides
integrity protection for these values. integrity protection for these values.
enum { enum {
quic_transport_parameters(0xffa5), (65535) quic_transport_parameters(0xffa5), (65535)
} ExtensionType; } ExtensionType;
The "extension_data" field of the quic_transport_parameters extension The extension_data field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in contains a value that is defined by the version of QUIC that is in
use. use.
The quic_transport_parameters extension is carried in the ClientHello The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake. Endpoints and the EncryptedExtensions messages during the handshake. Endpoints
MUST send the quic_transport_parameters extension; endpoints that MUST send the quic_transport_parameters extension; endpoints that
receive ClientHello or EncryptedExtensions messages without the receive ClientHello or EncryptedExtensions messages without the
quic_transport_parameters extension MUST close the connection with an quic_transport_parameters extension MUST close the connection with an
error of type 0x16d (equivalent to a fatal TLS missing_extension error of type 0x16d (equivalent to a fatal TLS missing_extension
alert, see Section 4.9). alert, see Section 4.10).
While the transport parameters are technically available prior to the While the transport parameters are technically available prior to the
completion of the handshake, they cannot be fully trusted until the completion of the handshake, they cannot be fully trusted until the
handshake completes, and reliance on them should be minimized. handshake completes, and reliance on them should be minimized.
However, any tampering with the parameters will cause the handshake However, any tampering with the parameters will cause the handshake
to fail. to fail.
Endpoints MUST NOT send this extension in a TLS connection that does Endpoints MUST NOT send this extension in a TLS connection that does
not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A
fatal unsupported_extension alert MUST be sent by an implementation fatal unsupported_extension alert MUST be sent by an implementation
skipping to change at page 37, line 30 skipping to change at page 39, line 12
rely on this message to mark the end of 0-RTT data or to signal the rely on this message to mark the end of 0-RTT data or to signal the
change to Handshake keys. change to Handshake keys.
Clients MUST NOT send the EndOfEarlyData message. A server MUST Clients MUST NOT send the EndOfEarlyData message. A server MUST
treat receipt of a CRYPTO frame in a 0-RTT packet as a connection treat receipt of a CRYPTO frame in a 0-RTT packet as a connection
error of type PROTOCOL_VIOLATION. error of type PROTOCOL_VIOLATION.
As a result, EndOfEarlyData does not appear in the TLS handshake As a result, EndOfEarlyData does not appear in the TLS handshake
transcript. transcript.
8.4. Prohibit TLS Middlebox Compatibility Mode
Appendix D.4 of [TLS13] describes an alteration to the TLS 1.3
handshake as a workaround for bugs in some middleboxes. The TLS 1.3
middlebox compatibility mode involves setting the legacy_session_id
field to a 32-byte value in the ClientHello and ServerHello, then
sending a change_cipher_spec record. Both field and record carry no
semantic content and are ignored.
This mode has no use in QUIC as it only applies to middleboxes that
interfere with TLS over TCP. QUIC also provides no means to carry a
change_cipher_spec record. A client MUST NOT request the use of the
TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a
TLS ClientHello that with a non-empty legacy_session_id field as a
connection error of type PROTOCOL_VIOLATION.
9. Security Considerations 9. Security Considerations
There are likely to be some real clangers here eventually, but the All of the security considerations that apply to TLS also apply to
current set of issues is well captured in the relevant sections of the use of TLS in QUIC. Reading all of [TLS13] and its appendices is
the main text. the best way to gain an understanding of the security properties of
QUIC.
Never assume that because it isn't in the security considerations This section summarizes some of the more important security aspects
section it doesn't affect security. Most of this document does. specific to the TLS integration, though there are many security-
relevant details in the remainder of the document.
9.1. Replay Attacks with 0-RTT 9.1. Session Linkability
Use of TLS session tickets allows servers and possibly other entities
to correlate connections made by the same client; see Section 4.5 for
details.
9.2. Replay Attacks with 0-RTT
As described in Section 8 of [TLS13], use of TLS early data comes As described in Section 8 of [TLS13], use of TLS early data comes
with an exposure to replay attack. The use of 0-RTT in QUIC is with an exposure to replay attack. The use of 0-RTT in QUIC is
similarly vulnerable to replay attack. similarly vulnerable to replay attack.
Endpoints MUST implement and use the replay protections described in Endpoints MUST implement and use the replay protections described in
[TLS13], however it is recognized that these protections are [TLS13], however it is recognized that these protections are
imperfect. Therefore, additional consideration of the risk of replay imperfect. Therefore, additional consideration of the risk of replay
is needed. is needed.
skipping to change at page 38, line 36 skipping to change at page 40, line 45
that carry application semantics. that carry application semantics.
Disabling 0-RTT entirely is the most effective defense against replay Disabling 0-RTT entirely is the most effective defense against replay
attack. attack.
QUIC extensions MUST describe how replay attacks affect their QUIC extensions MUST describe how replay attacks affect their
operation, or prohibit their use in 0-RTT. Application protocols operation, or prohibit their use in 0-RTT. Application protocols
MUST either prohibit the use of extensions that carry application MUST either prohibit the use of extensions that carry application
semantics in 0-RTT or provide replay mitigation strategies. semantics in 0-RTT or provide replay mitigation strategies.
9.2. Packet Reflection Attack Mitigation 9.3. Packet Reflection Attack Mitigation
A small ClientHello that results in a large block of handshake A small ClientHello that results in a large block of handshake
messages from a server can be used in packet reflection attacks to messages from a server can be used in packet reflection attacks to
amplify the traffic generated by an attacker. amplify the traffic generated by an attacker.
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. Header Protection Analysis 9.4. Header Protection Analysis
[NAN] analyzes authenticated encryption algorithms which provide [NAN] analyzes authenticated encryption algorithms which provide
nonce privacy, referred to as "Hide Nonce" (HN) transforms. The nonce privacy, referred to as "Hide Nonce" (HN) transforms. The
general header protection construction in this document is one of general header protection construction in this document is one of
those algorithms (HN1). Header protection uses the output of the those algorithms (HN1). Header protection uses the output of the
packet protection AEAD to derive "sample", and then encrypts the packet protection AEAD to derive "sample", and then encrypts the
header field using a pseudorandom function (PRF) as follows: header field using a pseudorandom function (PRF) as follows:
protected_field = field XOR PRF(hp_key, sample) protected_field = field XOR PRF(hp_key, sample)
skipping to change at page 39, line 35 skipping to change at page 41, line 44
a PRF to ensure equivalent security guarantees. a PRF to ensure equivalent security guarantees.
Use of the same key and ciphertext sample more than once risks Use of the same key and ciphertext sample more than once risks
compromising header protection. Protecting two different headers compromising header protection. Protecting two different headers
with the same key and ciphertext sample reveals the exclusive OR of with the same key and ciphertext sample reveals the exclusive OR of
the protected fields. Assuming that the AEAD acts as a PRF, if L the protected fields. Assuming that the AEAD acts as a PRF, if L
bits are sampled, the odds of two ciphertext samples being identical bits are sampled, the odds of two ciphertext samples being identical
approach 2^(-L/2), that is, the birthday bound. For the algorithms approach 2^(-L/2), that is, the birthday bound. For the algorithms
described in this document, that probability is one in 2^64. described in this document, that probability is one in 2^64.
Note: In some cases, inputs shorter than the full size required by
the packet protection algorithm might be used.
To prevent an attacker from modifying packet headers, the header is To prevent an attacker from modifying packet headers, the header is
transitively authenticated using packet protection; the entire packet transitively authenticated using packet protection; the entire packet
header is part of the authenticated additional data. Protected header is part of the authenticated additional data. Protected
fields that are falsified or modified can only be detected once the fields that are falsified or modified can only be detected once the
packet protection is removed. packet protection is removed.
9.4. Header Protection Timing Side-Channels 9.5. Header Protection Timing Side-Channels
An attacker could guess values for packet numbers or Key Phase and An attacker could guess values for packet numbers or Key Phase and
have an endpoint confirm guesses through timing side channels. have an endpoint confirm guesses through timing side channels.
Similarly, guesses for the packet number length can be trialed and Similarly, guesses for the packet number length can be trialed and
exposed. If the recipient of a packet discards packets with exposed. If the recipient of a packet discards packets with
duplicate packet numbers without attempting to remove packet duplicate packet numbers without attempting to remove packet
protection they could reveal through timing side-channels that the protection they could reveal through timing side-channels that the
packet number matches a received packet. For authentication to be packet number matches a received packet. For authentication to be
free from side-channels, the entire process of header protection free from side-channels, the entire process of header protection
removal, packet number recovery, and packet protection removal MUST removal, packet number recovery, and packet protection removal MUST
skipping to change at page 40, line 30 skipping to change at page 42, line 40
Phase. Phase.
This depends on not doing this key generation during packet This depends on not doing this key generation during packet
processing and it can require that endpoints maintain three sets of processing and it can require that endpoints maintain three sets of
packet protection keys for receiving: for the previous key phase, for packet protection keys for receiving: for the previous key phase, for
the current key phase, and for the next key phase. Endpoints can the current key phase, and for the next key phase. Endpoints can
instead choose to defer generation of the next receive packet instead choose to defer generation of the next receive packet
protection keys until they discard old keys so that only two sets of protection keys until they discard old keys so that only two sets of
receive keys need to be retained at any point in time. receive keys need to be retained at any point in time.
9.5. Key Diversity 9.6. 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 41, line 43 skipping to change at page 44, line 8
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", Work in Progress, Internet-Draft, and Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-27, 21 February 2020, draft-ietf-quic-recovery-28, 20 May 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-27>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-28>.
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", Work in Progress, Multiplexed and Secure Transport", Work in Progress,
Internet-Draft, draft-ietf-quic-transport-27, 21 February Internet-Draft, draft-ietf-quic-transport-28, 20 May 2020,
2020, <https://tools.ietf.org/html/draft-ietf-quic- <https://tools.ietf.org/html/draft-ietf-quic-transport-
transport-27>. 28>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 42, line 35 skipping to change at page 44, line 48
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
[AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", 8 March 2016, Encryption Use in TLS", 8 March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[HTTP2-TLS13] [HTTP2-TLS13]
Benjamin, D., "Using TLS 1.3 with HTTP/2", Work in Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
Progress, Internet-Draft, draft-ietf-httpbis- DOI 10.17487/RFC8740, February 2020,
http2-tls13-03, 17 October 2019, <http://www.ietf.org/ <https://www.rfc-editor.org/info/rfc8740>.
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, 6 Cryptography, Second Edition", ISBN 978-1466570269, 6
November 2014. November 2014.
[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", DOI 10.1007/978-3-030-26948-7_9, Advances AEAD Revisited", DOI 10.1007/978-3-030-26948-7_9, Advances
in Cryptology - CRYPTO 2019 pp. 235-265, 2019, in Cryptology - CRYPTO 2019 pp. 235-265, 2019,
<https://doi.org/10.1007/978-3-030-26948-7_9>. <https://doi.org/10.1007/978-3-030-26948-7_9>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-27, 21 February 2020, quic-http-28, 20 May 2020,
<https://tools.ietf.org/html/draft-ietf-quic-http-27>. <https://tools.ietf.org/html/draft-ietf-quic-http-28>.
[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 44, line 52 skipping to change at page 47, line 16
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:
c3ff00001b088394c8f03e5157080000449e00000002 c3ff00001c088394c8f03e5157080000449e00000002
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[18..21] ^= mask[1..4] header[18..21] ^= mask[1..4]
= 3b343aa8 = 3b343aa8
header = c0ff00001b088394c8f03e5157080000449e3b343aa8 header = c0ff00001c088394c8f03e5157080000449e3b343aa8
The resulting protected packet is: The resulting protected packet is:
c0ff00001b088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c c0ff00001c088394c8f03e5157080000 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 46, line 42 skipping to change at page 48, 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
38d3b779d72edc00c5cd088eff802b05 ea5388b911e76d2856d68cf6cf394185
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:
c1ff00001b0008f067a5502a4262b50040740001 c1ff00001c0008f067a5502a4262b50040740001
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 = c9ff00001b0008f067a5502a4262b5004074168b header = c9ff00001c0008f067a5502a4262b5004074168b
The final protected packet is then: The final protected packet is then:
c9ff00001b0008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a c9ff00001c0008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493 5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3 537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92bd8c3a9528d2b6aca20f0 cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92bda5b23c81034ab74f54c
8047d9f017f0 b1bd72951256
A.4. Retry A.4. Retry
This shows a Retry packet that might be sent in response to the This shows a Retry packet that might be sent in response to the
Initial packet in Appendix A.2. The integrity check includes the Initial packet in Appendix A.2. The integrity check includes the
client-chosen connection ID value of 0x8394c8f03e515708, but that client-chosen connection ID value of 0x8394c8f03e515708, but that
value is not included in the final Retry packet: value is not included in the final Retry packet:
ffff00001b0008f067a5502a4262b574 6f6b656ea523cb5ba524695f6569f293 ffff00001c0008f067a5502a4262b574 6f6b656ef71a5f12afe3ecf8001a920e
a1359d8e 6fdf1d63
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-26 B.1. Since draft-ietf-quic-tls-27
* Updated examples * Allowed CONNECTION_CLOSE in any packet number space, with
restrictions on use of the application-specific variant (#3430,
#3435, #3440)
B.2. Since draft-ietf-quic-tls-25 * Prohibit the use of the compatibility mode from TLS 1.3 (#3594,
#3595)
B.2. Since draft-ietf-quic-tls-26
* No changes * No changes
B.3. Since draft-ietf-quic-tls-24 B.3. Since draft-ietf-quic-tls-25
* No changes
B.4. Since draft-ietf-quic-tls-24
* Rewrite key updates (#3050) * Rewrite key updates (#3050)
- Allow but don't recommend deferring key updates (#2792, #3263) - Allow but don't recommend deferring key updates (#2792, #3263)
- More completely define received behavior (#2791) - More completely define received behavior (#2791)
- Define the label used with HKDF-Expand-Label (#3054) - Define the label used with HKDF-Expand-Label (#3054)
B.4. Since draft-ietf-quic-tls-23 B.5. Since draft-ietf-quic-tls-23
* Key update text update (#3050): * Key update text update (#3050):
- Recommend constant-time key replacement (#2792) - Recommend constant-time key replacement (#2792)
- Provide explicit labels for key update key derivation (#3054) - Provide explicit labels for key update key derivation (#3054)
* Allow first Initial from a client to span multiple packets (#2928, * Allow first Initial from a client to span multiple packets (#2928,
#3045) #3045)
* PING can be sent at any encryption level (#3034, #3035) * PING can be sent at any encryption level (#3034, #3035)
B.5. Since draft-ietf-quic-tls-22 B.6. Since draft-ietf-quic-tls-22
* Update the salt used for Initial secrets (#2887, #2980) * Update the salt used for Initial secrets (#2887, #2980)
B.6. Since draft-ietf-quic-tls-21 B.7. Since draft-ietf-quic-tls-21
* No changes * No changes
B.7. Since draft-ietf-quic-tls-20 B.8. Since draft-ietf-quic-tls-20
* Mandate the use of the QUIC transport parameters extension (#2528, * Mandate the use of the QUIC transport parameters extension (#2528,
#2560) #2560)
* Define handshake completion and confirmation; define clearer rules * Define handshake completion and confirmation; define clearer rules
when it encryption keys should be discarded (#2214, #2267, #2673) when it encryption keys should be discarded (#2214, #2267, #2673)
B.8. Since draft-ietf-quic-tls-18 B.9. Since draft-ietf-quic-tls-18
* Increased the set of permissible frames in 0-RTT (#2344, #2355) * Increased the set of permissible frames in 0-RTT (#2344, #2355)
* Transport parameter extension is mandatory (#2528, #2560) * Transport parameter extension is mandatory (#2528, #2560)
B.9. Since draft-ietf-quic-tls-17 B.10. Since draft-ietf-quic-tls-17
* Endpoints discard initial keys as soon as handshake keys are * Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
* Use of ALPN or equivalent is mandatory (#2263, #2284) * Use of ALPN or equivalent is mandatory (#2263, #2284)
B.10. Since draft-ietf-quic-tls-14 B.11. Since draft-ietf-quic-tls-14
* Update the salt used for Initial secrets (#1970) * Update the salt used for Initial secrets (#1970)
* Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) * Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
* Change header protection * Change header protection
- Sample from a fixed offset (#1575, #2030) - Sample from a fixed offset (#1575, #2030)
- Cover part of the first byte, including the key phase (#1322, - Cover part of the first byte, including the key phase (#1322,
skipping to change at page 49, line 32 skipping to change at page 51, line 41
* TLS provides an AEAD and KDF function (#2046) * TLS provides an AEAD and KDF function (#2046)
- Clarify that the TLS KDF is used with TLS (#1997) - Clarify that the TLS KDF is used with TLS (#1997)
- Change the labels for calculation of QUIC keys (#1845, #1971, - Change the labels for calculation of QUIC keys (#1845, #1971,
#1991) #1991)
* Initial keys are discarded once Handshake keys are available * Initial keys are discarded once Handshake keys are available
(#1951, #2045) (#1951, #2045)
B.11. Since draft-ietf-quic-tls-13 B.12. Since draft-ietf-quic-tls-13
* Updated to TLS 1.3 final (#1660) * Updated to TLS 1.3 final (#1660)
B.12. Since draft-ietf-quic-tls-12 B.13. Since draft-ietf-quic-tls-12
* Changes to integration of the TLS handshake (#829, #1018, #1094, * Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450) #1165, #1190, #1233, #1242, #1252, #1450)
- The cryptographic handshake uses CRYPTO frames, not stream 0 - The cryptographic handshake uses CRYPTO frames, not stream 0
- QUIC packet protection is used in place of TLS record - QUIC packet protection is used in place of TLS record
protection protection
- Separate QUIC packet number spaces are used for the handshake - Separate QUIC packet number spaces are used for the handshake
- Changed Retry to be independent of the cryptographic handshake - Changed Retry to be independent of the cryptographic handshake
- Limit the use of HelloRetryRequest to address TLS needs (like - Limit the use of HelloRetryRequest to address TLS needs (like
key shares) key shares)
* Changed codepoint of TLS extension (#1395, #1402) * Changed codepoint of TLS extension (#1395, #1402)
B.13. Since draft-ietf-quic-tls-11 B.14. Since draft-ietf-quic-tls-11
* Encrypted packet numbers. * Encrypted packet numbers.
B.14. Since draft-ietf-quic-tls-10 B.15. Since draft-ietf-quic-tls-10
* No significant changes. * No significant changes.
B.15. Since draft-ietf-quic-tls-09 B.16. Since draft-ietf-quic-tls-09
* Cleaned up key schedule and updated the salt used for handshake * Cleaned up key schedule and updated the salt used for handshake
packet protection (#1077) packet protection (#1077)
B.16. Since draft-ietf-quic-tls-08 B.17. Since draft-ietf-quic-tls-08
* Specify value for max_early_data_size to enable 0-RTT (#942) * Specify value for max_early_data_size to enable 0-RTT (#942)
* Update key derivation function (#1003, #1004) * Update key derivation function (#1003, #1004)
B.17. Since draft-ietf-quic-tls-07 B.18. Since draft-ietf-quic-tls-07
* Handshake errors can be reported with CONNECTION_CLOSE (#608, * Handshake errors can be reported with CONNECTION_CLOSE (#608,
#891) #891)
B.18. Since draft-ietf-quic-tls-05 B.19. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
B.19. Since draft-ietf-quic-tls-04 B.20. Since draft-ietf-quic-tls-04
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.20. Since draft-ietf-quic-tls-03 B.21. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
B.21. Since draft-ietf-quic-tls-02 B.22. Since draft-ietf-quic-tls-02
* Updates to match changes in transport draft * Updates to match changes in transport draft
B.22. Since draft-ietf-quic-tls-01 B.23. Since draft-ietf-quic-tls-01
* Use TLS alerts to signal TLS errors (#272, #374) * Use TLS alerts to signal TLS errors (#272, #374)
* Require ClientHello to fit in a single packet (#338) * Require ClientHello to fit in a single packet (#338)
* The second client handshake flight is now sent in the clear (#262, * The second client handshake flight is now sent in the clear (#262,
#337) #337)
* The QUIC header is included as AEAD Associated Data (#226, #243, * The QUIC header is included as AEAD Associated Data (#226, #243,
#302) #302)
* Add interface necessary for client address validation (#275) * Add interface necessary for client address validation (#275)
* Define peer authentication (#140) * Define peer authentication (#140)
* Require at least TLS 1.3 (#138) * Require at least TLS 1.3 (#138)
* Define transport parameters as a TLS extension (#122) * Define transport parameters as a TLS extension (#122)
* Define handling for protected packets before the handshake * Define handling for protected packets before the handshake
completes (#39) completes (#39)
* Decouple QUIC version and ALPN (#12) * Decouple QUIC version and ALPN (#12)
B.23. Since draft-ietf-quic-tls-00 B.24. Since draft-ietf-quic-tls-00
* Changed bit used to signal key phase * Changed bit used to signal key phase
* Updated key phase markings during the handshake * Updated key phase markings during the handshake
* Added TLS interface requirements section * Added TLS interface requirements section
* Moved to use of TLS exporters for key derivation * Moved to use of TLS exporters for key derivation
* Moved TLS error code definitions into this document * Moved TLS error code definitions into this document
B.24. Since draft-thomson-quic-tls-01 B.25. Since draft-thomson-quic-tls-01
* Adopted as base for draft-ietf-quic-tls * Adopted as base for draft-ietf-quic-tls
* Updated authors/editors list * Updated authors/editors list
* Added status note * Added status note
Contributors Contributors
The IETF QUIC Working Group received an enormous amount of support The IETF QUIC Working Group received an enormous amount of support
from many people. The following people provided substantive from many people. The following people provided substantive
contributions to this document: Adam Langley, Alessandro Ghedini, contributions to this document:
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 * 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
* Victor Vasiliev
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
Email: sean@sn3rd.com Email: sean@sn3rd.com
 End of changes. 102 change blocks. 
300 lines changed or deleted 413 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/