draft-ietf-quic-tls-23.txt   draft-ietf-quic-tls-latest.txt 
QUIC Working Group M. Thomson, Ed. QUIC Working Group M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Turner, Ed. Intended status: Standards Track S. Turner, Ed.
Expires: March 15, 2020 sn3rd Expires: April 19, 2020 sn3rd
September 12, 2019 October 17, 2019
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-23 draft-ietf-quic-tls-latest
Abstract Abstract
This document describes how Transport Layer Security (TLS) is used to This document describes how Transport Layer Security (TLS) is used to
secure QUIC. secure QUIC.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2020. This Internet-Draft will expire on April 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8 4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8
4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10 4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10
4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10 4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10
4.1.3. Sending and Receiving Handshake Messages . . . . . . 10 4.1.3. Sending and Receiving Handshake Messages . . . . . . 10
4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12 4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12
4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13 4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13
4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 14 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15
4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15 4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15
4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15 4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 16
4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16 4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16
4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 16 4.7. Validating 0-RTT Configuration . . . . . . . . . . . . . 17
4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 16 4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 17
4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 17 4.9. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 18
4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 17 4.10. Discarding Unused Keys . . . . . . . . . . . . . . . . . 18
4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 18 4.10.1. Discarding Initial Keys . . . . . . . . . . . . . . 18
4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 18 4.10.2. Discarding Handshake Keys . . . . . . . . . . . . . 19
5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 18 4.10.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 19
5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 18 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 19 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 20
5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 20
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 21 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 21
5.4.1. Header Protection Application . . . . . . . . . . . . 22 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 22
5.4.2. Header Protection Sample . . . . . . . . . . . . . . 23 5.4.1. Header Protection Application . . . . . . . . . . . . 23
5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 24 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 25
5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 25 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 26
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 25 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 26
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 25 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 27
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 26 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 27
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 28
7. Security of Initial Messages . . . . . . . . . . . . . . . . 29 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30 7. Security of Initial Messages . . . . . . . . . . . . . . . . 30
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 30 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 31
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 30 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 31
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 31 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 32
9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 32 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 33
9.3. Header Protection Analysis . . . . . . . . . . . . . . . 33 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 34
9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 34 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 34
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Sample Initial Packet Protection . . . . . . . . . . 36 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Sample Initial Packet Protection . . . . . . . . . . 38
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 38 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 39 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 39
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 40 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 41
B.1. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 40 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 42
B.2. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 40 B.1. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 42
B.3. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 40 B.2. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 42
B.4. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 40 B.3. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 42
B.5. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 41 B.4. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 42
B.6. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 41 B.5. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 43
B.7. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 41 B.6. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 43
B.8. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 41 B.7. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 43
B.9. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 42 B.8. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 43
B.10. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 42 B.9. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 44
B.11. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 42 B.10. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 44
B.12. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 42 B.11. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 44
B.13. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 42 B.12. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 44
B.14. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 42 B.13. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 44
B.15. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 42 B.14. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 44
B.16. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 42 B.15. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 44
B.17. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 42 B.16. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 44
B.18. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 43 B.17. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 44
B.19. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 43 B.18. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 45
B.20. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 43 B.19. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 B.20. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 45
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document describes how QUIC [QUIC-TRANSPORT] is secured using This document describes how QUIC [QUIC-TRANSPORT] is secured using
TLS [TLS13]. TLS [TLS13].
TLS 1.3 provides critical latency improvements for connection TLS 1.3 provides critical latency improvements for connection
establishment over previous versions. Absent packet loss, most new establishment over previous versions. Absent packet loss, most new
connections can be established and secured within a single round connections can be established and secured within a single round
trip; on subsequent connections between the same client and server, trip; on subsequent connections between the same client and server,
skipping to change at page 8, line 5 skipping to change at page 8, line 5
TLS. TLS.
o The TLS component provides a series of updates to the QUIC o The TLS component provides a series of updates to the QUIC
component, including (a) new packet protection keys to install (b) component, including (a) new packet protection keys to install (b)
state changes such as handshake completion, the server state changes such as handshake completion, the server
certificate, etc. certificate, etc.
Figure 2 shows these interactions in more detail, with the QUIC Figure 2 shows these interactions in more detail, with the QUIC
packet protection being called out specially. packet protection being called out specially.
+------------+ +------------+ +------------+ +------------+
| |<- Handshake Messages ->| | | |<---- Handshake Messages ----->| |
| |<---- 0-RTT Keys -------| | | |<- Validate 0-RTT parameters ->| |
| |<--- Handshake Keys-----| | | |<--------- 0-RTT Keys ---------| |
| QUIC |<---- 1-RTT Keys -------| TLS | | QUIC |<------- Handshake Keys -------| TLS |
| |<--- Handshake Done ----| | | |<--------- 1-RTT Keys ---------| |
+------------+ +------------+ | |<------- Handshake Done -------| |
+------------+ +------------+
| ^ | ^
| Protect | Protected | Protect | Protected
v | Packet v | Packet
+------------+ +------------+
| QUIC | | QUIC |
| Packet | | Packet |
| Protection | | Protection |
+------------+ +------------+
Figure 2: QUIC and TLS Interactions Figure 2: QUIC and TLS Interactions
skipping to change at page 8, line 52 skipping to change at page 9, line 5
QUIC packet as long as they are associated with the same encryption QUIC packet as long as they are associated with the same encryption
level. For instance, an implementation might bundle a Handshake level. For instance, an implementation might bundle a Handshake
message and an ACK for some Handshake data into the same packet. message and an ACK for some Handshake data into the same packet.
Some frames are prohibited in different encryption levels, others Some frames are prohibited in different encryption levels, others
cannot be sent. The rules here generalize those of TLS, in that cannot be sent. The rules here generalize those of TLS, in that
frames associated with establishing the connection can usually appear frames associated with establishing the connection can usually appear
at any encryption level, whereas those associated with transferring at any encryption level, whereas those associated with transferring
data can only appear in the 0-RTT and 1-RTT encryption levels: data can only appear in the 0-RTT and 1-RTT encryption levels:
o PADDING frames MAY appear in packets of any encryption level. o PADDING and PING frames MAY appear in packets of any encryption
level.
o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any
encryption level except 0-RTT. encryption level except 0-RTT.
o ACK frames MAY appear in packets of any encryption level other o ACK frames MAY appear in packets of any encryption level other
than 0-RTT, but can only acknowledge packets which appeared in than 0-RTT, but can only acknowledge packets which appeared in
that packet number space. that packet number space.
o All other frame types MUST only be sent in the 0-RTT and 1-RTT o All other frame types MUST only be sent in the 0-RTT and 1-RTT
levels. levels.
skipping to change at page 9, line 48 skipping to change at page 10, line 7
| Short Header | 1-RTT | 0/1-RTT | | Short Header | 1-RTT | 0/1-RTT |
+---------------------+------------------+-----------+ +---------------------+------------------+-----------+
Table 1: Encryption Levels by Packet Type Table 1: Encryption Levels by Packet Type
Section 17 of [QUIC-TRANSPORT] shows how packets at the various Section 17 of [QUIC-TRANSPORT] shows how packets at the various
encryption levels fit into the handshake process. encryption levels fit into the handshake process.
4.1. Interface to TLS 4.1. Interface to TLS
As shown in Figure 2, the interface from QUIC to TLS consists of As shown in Figure 2, the interface from QUIC to TLS consists of four
three primary functions: primary functions:
o Sending and receiving handshake messages o Sending and receiving handshake messages
o Processing stored transport and application state from a resumed
session and determining if it is valid to accept early data
o Rekeying (both transmit and receive) o Rekeying (both transmit and receive)
o Handshake state updates o Handshake state updates
Additional functions might be needed to configure TLS. Additional functions might be needed to configure TLS.
4.1.1. Handshake Complete 4.1.1. Handshake Complete
In this document, the TLS handshake is considered complete when the In this document, the TLS handshake is considered complete when the
TLS stack has reported that the handshake is complete. This happens TLS stack has reported that the handshake is complete. This happens
skipping to change at page 10, line 48 skipping to change at page 11, line 10
where QUIC provides handshake packets. where QUIC provides handshake packets.
Before starting the handshake QUIC provides TLS with the transport Before starting the handshake QUIC provides TLS with the transport
parameters (see Section 8.2) that it wishes to carry. parameters (see Section 8.2) that it wishes to carry.
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 given time, the TLS stack at an endpoint will have a current At any time, the TLS stack at an endpoint will have a current sending
sending encryption level and receiving encryption level. Each encryption level and receiving encryption level. Each encryption
encryption level is associated with a different flow of bytes, which level is associated with a different flow of bytes, which is reliably
is reliably transmitted to the peer in CRYPTO frames. When TLS transmitted to the peer in CRYPTO frames. When TLS provides
provides handshake bytes to be sent, they are appended to the current handshake bytes to be sent, they are appended to the current flow and
flow and any packet that includes the CRYPTO frame is protected using any packet that includes the CRYPTO frame is protected using keys
keys from the corresponding encryption level. from the corresponding encryption level.
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
frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error
codes; see Section 4.9. TLS application data and other message types
cannot be carried by QUIC at any encryption level and is an error if
they are received from the TLS stack.
When an endpoint receives a QUIC packet containing a CRYPTO frame When an endpoint receives a QUIC packet containing a CRYPTO frame
from the network, it proceeds as follows: from the network, it proceeds as follows:
o If the packet was in the TLS receiving encryption level, sequence o If the packet was in the TLS receiving encryption level, sequence
the data into the input flow as usual. As with STREAM frames, the the data into the input flow as usual. As with STREAM frames, the
offset is used to find the proper location in the data sequence. offset is used to find the proper location in the data sequence.
If the result of this process is that new data is available, then If the result of this process is that new data is available, then
it is delivered to TLS in order. it is delivered to TLS in order.
o If the packet is from a previously installed encryption level, it o If the packet is from a previously installed encryption level, it
skipping to change at page 15, line 28 skipping to change at page 16, line 12
A client MUST authenticate the identity of the server. This A client MUST authenticate the identity of the server. This
typically involves verification that the identity of the server is typically involves verification that the identity of the server is
included in a certificate and that the certificate is issued by a included in a certificate and that the certificate is issued by a
trusted entity (see for example [RFC2818]). trusted entity (see for example [RFC2818]).
A server MAY request that the client authenticate during the A server MAY request that the client authenticate during the
handshake. A server MAY refuse a connection if the client is unable handshake. A server MAY refuse a connection if the client is unable
to authenticate when requested. The requirements for client to authenticate when requested. The requirements for client
authentication vary based on application protocol and deployment. authentication vary based on application protocol and deployment.
A server MUST NOT use post-handshake client authentication (see A server MUST NOT use post-handshake client authentication (as
Section 4.6.2 of [TLS13]). defined in Section 4.6.2 of [TLS13]), because the multiplexing
offered by QUIC prevents clients from correlating the certificate
request with the application-level event that triggered it (see
[HTTP2-TLS13]). More specifically, servers MUST NOT send post-
handshake TLS CertificateRequest messages and clients MUST treat
receipt of such messages as a connection error of type
PROTOCOL_VIOLATION.
4.5. Enabling 0-RTT 4.5. Enabling 0-RTT
In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket To communicate their willingness to process 0-RTT data, servers send
message that contains the "early_data" extension with a a NewSessionTicket message that contains the "early_data" extension
max_early_data_size of 0xffffffff; the amount of data which the with a max_early_data_size of 0xffffffff; the amount of data which
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. A client MUST treat transport parameter supplied by the server. Servers MUST NOT send
receipt of a NewSessionTicket that contains an "early_data" extension the "early_data" extension with a max_early_data_size set to any
with any other value as a connection error of type value other than 0xffffffff. A client MUST treat receipt of a
PROTOCOL_VIOLATION. NewSessionTicket that contains an "early_data" extension with any
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.
Early data within the TLS connection MUST NOT be used. As it is for
other TLS application data, a server MUST treat receiving early data
on the TLS connection as a connection error of type
PROTOCOL_VIOLATION.
4.6. Accepting and Rejecting 0-RTT 4.6. 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
skipping to change at page 16, line 29 skipping to change at page 17, line 15
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. HelloRetryRequest 4.7. Validating 0-RTT Configuration
When a server receives a ClientHello with the "early_data" extension,
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.,
checking that the cipher suite being resumed was included in the
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
protocol using QUIC might reject early data because the configuration
of the transport or application associated with the resumed session
is not compatible with the server's current configuration.
QUIC requires additional transport state to be associated with a
0-RTT session ticket. One common way to implement this is using
stateless session tickets and storing this state in the session
ticket. Application protocols that use QUIC might have similar
requirements regarding associating or storing state. This associated
state is used for deciding whether early data must be rejected. For
example, HTTP/3 ([QUIC-HTTP]) settings determine how early data from
the client is interpreted. Other applications using QUIC could have
different requirements for determining whether to accept or reject
early data.
4.8. 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 the Initial encryption level. Although it is in principle
possible to use this feature for address verification in QUIC, QUIC possible to use this feature for address verification in QUIC, QUIC
implementations SHOULD instead use the Retry feature (see Section 8.1 implementations SHOULD instead use the Retry feature (see Section 8.1
of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key
shares. shares.
4.8. TLS Errors 4.9. 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 turned into a QUIC connection error by converting the
one-byte alert description into a QUIC error code. 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.
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.9. Discarding Unused Keys 4.10. 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 17, line 37 skipping to change at page 18, line 48
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.9.1. Discarding Initial Keys 4.10.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.9.2. Discarding Handshake Keys 4.10.2. Discarding Handshake Keys
An endpoint MUST NOT discard its handshake keys until the TLS An endpoint MUST NOT discard its handshake keys until the TLS
handshake is confirmed (Section 4.1.2). An endpoint SHOULD discard handshake is confirmed (Section 4.1.2). An endpoint SHOULD discard
its handshake keys as soon as it has confirmed the handshake. Most its handshake keys as soon as it has confirmed the handshake. Most
application protocols will send data after the handshake, resulting application protocols will send data after the handshake, resulting
in acknowledgements that allow both endpoints to discard their in acknowledgements that allow both endpoints to discard their
handshake keys promptly. Endpoints that do not have reason to send handshake keys promptly. Endpoints that do not have reason to send
immediately after completing the handshake MAY send ack-eliciting immediately after completing the handshake MAY send ack-eliciting
frames, such as PING, which will cause the handshake to be confirmed frames, such as PING, which will cause the handshake to be confirmed
when they are acknowledged. when they are acknowledged.
4.9.3. Discarding 0-RTT Keys 4.10.3. Discarding 0-RTT Keys
0-RTT and 1-RTT packets share the same packet number space, and 0-RTT and 1-RTT packets share the same packet number space, and
clients do not send 0-RTT packets after sending a 1-RTT packet clients do not send 0-RTT packets after sending a 1-RTT packet
(Section 5.6). (Section 5.6).
Therefore, a client SHOULD discard 0-RTT keys as soon as it installs Therefore, a client SHOULD discard 0-RTT keys as soon as it installs
1-RTT keys, since they have no use after that moment. 1-RTT keys, since they have no use after that moment.
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 27, line 40 skipping to change at page 29, line 17
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 necessarily needing to receive the first packet that material without necessarily needing to receive the first packet that
triggered the change. An endpoint that notices a changed KEY_PHASE triggered the change. An endpoint that notices a changed KEY_PHASE
bit can update keys and decrypt the packet that contains the changed bit can update keys and decrypt the packet that contains the changed
bit. bit.
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.8). Section 4.9).
An endpoint MUST NOT initiate the first key update until the An endpoint MUST NOT initiate the first key update until the
handshake is confirmed (Section 4.1.2). An endpoint MUST NOT handshake is confirmed (Section 4.1.2). An endpoint MUST NOT
initiate a subsequent key update until it has received an initiate a subsequent key update until it has received an
acknowledgment for a packet sent at the current KEY_PHASE. This can acknowledgment for a packet sent at the current KEY_PHASE. This can
be implemented by tracking the lowest packet number sent with each be implemented by tracking the lowest packet number sent with each
KEY_PHASE, and the highest acknowledged packet number in the 1-RTT KEY_PHASE, and the highest acknowledged packet number in the 1-RTT
space: once the latter is higher than or equal to the former, another space: once the latter is higher than or equal to the former, another
key update can be initiated. key update can be initiated.
skipping to change at page 30, line 22 skipping to change at page 31, line 39
8.1. Protocol Negotiation 8.1. Protocol Negotiation
QUIC requires that the cryptographic handshake provide authenticated QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation. TLS uses Application Layer Protocol protocol negotiation. TLS uses Application Layer Protocol
Negotiation (ALPN) [RFC7301] to select an application protocol. Negotiation (ALPN) [RFC7301] to select an application protocol.
Unless another mechanism is used for agreeing on an application Unless another mechanism is used for agreeing on an application
protocol, endpoints MUST use ALPN for this purpose. When using ALPN, protocol, endpoints MUST use ALPN for this purpose. When using ALPN,
endpoints MUST immediately close a connection (see Section 10.3 in endpoints MUST immediately close a connection (see Section 10.3 in
[QUIC-TRANSPORT]) if an application protocol is not negotiated with a [QUIC-TRANSPORT]) if an application protocol is not negotiated with a
no_application_protocol TLS alert (QUIC error code 0x178, see no_application_protocol TLS alert (QUIC error code 0x178, see
Section 4.8). While [RFC7301] only specifies that servers use this Section 4.9). While [RFC7301] only specifies that servers use this
alert, QUIC clients MUST also use it to terminate a connection when alert, QUIC clients MUST also use it to terminate a connection when
ALPN negotiation fails. ALPN negotiation fails.
An application-layer protocol MAY restrict the QUIC versions that it An application-layer protocol MAY restrict the QUIC versions that it
can operate over. Servers MUST select an application protocol can operate over. Servers MUST select an application protocol
compatible with the QUIC version that the client has selected. If compatible with the QUIC version that the client has selected. If
the server cannot select a compatible combination of application the server cannot select a compatible combination of application
protocol and QUIC version, it MUST abort the connection. A client protocol and QUIC version, it MUST abort the connection. A client
MUST abort a connection if the server picks an application protocol MUST abort a connection if the server picks an application protocol
incompatible with the protocol version being used. incompatible with the protocol version being used.
skipping to change at page 31, line 11 skipping to change at page 32, line 29
use. The quic_transport_parameters extension carries a use. The quic_transport_parameters extension carries a
TransportParameters struct when the version of QUIC defined in TransportParameters struct when the version of QUIC defined in
[QUIC-TRANSPORT] is used. [QUIC-TRANSPORT] is used.
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.8). alert, see Section 4.9).
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 33, line 13 skipping to change at page 34, line 32
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.3. Header Protection Analysis
Header protection relies on the packet protection AEAD being a [NAN] analyzes authenticated encryption algorithms which provide
pseudorandom function (PRF), which is not a property that AEAD nonce privacy, referred to as "Hide Nonce" (HN) transforms. The
algorithms guarantee. Therefore, no strong assurances about the general header protection construction in this document is one of
general security of this mechanism can be shown in the general case. those algorithms (HN1). Header protection uses the output of the
The AEAD algorithms described in this document are assumed to be packet protection AEAD to derive "sample", and then encrypts the
PRFs. header field using a pseudorandom function (PRF) as follows:
The header protection algorithms defined in this document take the
form:
protected_field = field XOR PRF(hp_key, sample) protected_field = field XOR PRF(hp_key, sample)
This construction is secure against chosen plaintext attacks (IND- The header protection variants in this document use a pseudorandom
CPA) [IMC]. permutation (PRP) in place of a generic PRF. However, since all PRPs
are also PRFs [IMC], these variants do not deviate from the HN1
construction.
As "hp_key" is distinct from the packet protection key, it follows
that header protection achieves AE2 security as defined in [NAN] and
therefore guarantees privacy of "field", the protected packet header.
Future header protection variants based on this construction MUST use
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 Note: In some cases, inputs shorter than the full size required by
skipping to change at page 35, line 15 skipping to change at page 36, line 40
[AES] "Advanced encryption standard (AES)", National Institute [AES] "Advanced encryption standard (AES)", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.fips.197, November 2001. DOI 10.6028/nist.fips.197, November 2001.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-23 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-23 (work in progress). transport-latest (work in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
skipping to change at page 36, line 12 skipping to change at page 37, line 34
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
[AEBounds] [AEBounds]
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", March 2016, Encryption Use in TLS", March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[HTTP2-TLS13]
Benjamin, D., "Using TLS 1.3 with HTTP/2", draft-ietf-
httpbis-http2-tls13-02 (work in progress), September 2019.
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern [IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269, Cryptography, Second Edition", ISBN 978-1466570269,
November 2014. November 2014.
[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-23 (work in progress). QUIC", draft-ietf-quic-http-latest (work in progress).
[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 38, line 9 skipping to change at page 39, line 39
iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12) iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
= 5e5ae651fd1e8495af13508b = 5e5ae651fd1e8495af13508b
hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16) hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
= a8ed82e6664f865aedf6106943f95fb8 = a8ed82e6664f865aedf6106943f95fb8
A.2. Client Initial A.2. Client Initial
The client sends an Initial packet. The unprotected payload of this The client sends an Initial packet. The unprotected payload of this
packet contains the following CRYPTO frame, plus enough PADDING packet contains the following CRYPTO frame, plus enough PADDING
frames to make an 1163 byte payload: frames to make a 1162 byte payload:
060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1 060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1
4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006 4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
736572766572ff01000100000a001400 12001d00170018001901000101010201 736572766572ff01000100000a001400 12001d00170018001901000101010201
03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f 03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403 2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
05030603020308040805080604010501 060102010402050206020202002d0002 05030603020308040805080604010501 060102010402050206020202002d0002
0101001c00024001 0101001c00024001
The unprotected header includes the connection ID and a 4 byte packet The unprotected header includes the connection ID and a 4 byte packet
skipping to change at page 40, line 14 skipping to change at page 42, line 14
The header from the server includes a new connection ID and a 2-byte The header from the server includes a new connection ID and a 2-byte
packet number encoding for a packet number of 1: packet number encoding for a packet number of 1:
c1ff0000170008f067a5502a4262b50040740001 c1ff0000170008f067a5502a4262b50040740001
As a result, after protection, the header protection sample is taken As a result, after protection, the header protection sample is taken
starting from the third protected octet: starting from the third protected octet:
sample = 7002596f99ae67abf65a5852f54f58c3 sample = 7002596f99ae67abf65a5852f54f58c3
mask = 38168a0c25 mask = 38168a0c25
header = c1ff0000170008f067a5502a4262b5004074168b header = c9ff0000170008f067a5502a4262b5004074168b
The final protected packet is then: The final protected packet is then:
c9ff0000170008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a c9ff0000170008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493 5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3 537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b9cf9bb6d091ddfc8b32d cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b9cf9bb6d091ddfc8b32d
432348a2c413 432348a2c413
Appendix B. Change Log Appendix B. Change Log
 End of changes. 35 change blocks. 
128 lines changed or deleted 179 lines changed or added

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