draft-ietf-quic-tls-09.txt   draft-ietf-quic-tls-10.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: August 1, 2018 sn3rd Expires: September 6, 2018 sn3rd
January 28, 2018 March 05, 2018
Using Transport Layer Security (TLS) to Secure QUIC Using Transport Layer Security (TLS) to Secure QUIC
draft-ietf-quic-tls-09 draft-ietf-quic-tls-10
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 August 1, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . . . 6 3.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . . . 6
4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 7 4.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 8
4.2. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 4.2. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Handshake Interface . . . . . . . . . . . . . . . . . 9 4.2.1. Handshake Interface . . . . . . . . . . . . . . . . . 10
4.2.2. Source Address Validation . . . . . . . . . . . . . . 10 4.2.2. Source Address Validation . . . . . . . . . . . . . . 11
4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 11 4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 12
4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12 4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12
4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12 4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12
4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13 4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13
4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 13 4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 14
4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14
5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14 5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14
5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 14 5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 15
5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 15 5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 15
5.2.1. Handshake Secrets . . . . . . . . . . . . . . . . . . 15 5.2.1. QHKDF-Expand . . . . . . . . . . . . . . . . . . . . 15
5.2.2. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Handshake Secrets . . . . . . . . . . . . . . . . . . 16
5.2.3. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 16 5.2.3. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 17
5.2.4. Packet Protection Key and IV . . . . . . . . . . . . 17 5.2.4. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 17
5.2.5. Updating 1-RTT Secrets . . . . . . . . . . . . . . . 17
5.2.6. Packet Protection Keys . . . . . . . . . . . . . . . 18
5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 18 5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 18
5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18 5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 19
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 20
5.6. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 19 5.6. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 20
6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Packet Protection for the TLS Handshake . . . . . . . . . 20 6.1. Packet Protection for the TLS Handshake . . . . . . . . . 21
6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 20 6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 21
6.1.2. Retransmission and Acknowledgment of Unprotected 6.1.2. Retransmission and Acknowledgment of Unprotected
Packets . . . . . . . . . . . . . . . . . . . . . . . 21 Packets . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 23
7. Client Address Validation . . . . . . . . . . . . . . . . . . 24
7.1. HelloRetryRequest Address Validation . . . . . . . . . . 24 7. Client Address Validation . . . . . . . . . . . . . . . . . . 25
7.1.1. Stateless Address Validation . . . . . . . . . . . . 25 7.1. HelloRetryRequest Address Validation . . . . . . . . . . 25
7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 25 7.1.1. Stateless Address Validation . . . . . . . . . . . . 26
7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25 7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 26
7.3. Address Validation Token Integrity . . . . . . . . . . . 26 7.2. NewSessionTicket Address Validation . . . . . . . . . . . 26
8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26 7.3. Address Validation Token Integrity . . . . . . . . . . . 27
8.1. Unprotected Packets Prior to Handshake Completion . . . . 27 8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 27
8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27 8.1. Unprotected Packets Prior to Handshake Completion . . . . 28
8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28 8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 28
8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 28 8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 29
8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 29 8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 29
8.1.5. Denial of Service with Unprotected Packets . . . . . 29 8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 30
8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30 8.1.5. Address Verification . . . . . . . . . . . . . . . . 30
8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30 8.1.6. Denial of Service with Unprotected Packets . . . . . 30
9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30 8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 31
9.1. Protocol and Version Negotiation . . . . . . . . . . . . 31 8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 31
9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31 9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 32
9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Protocol and Version Negotiation . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 32
10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32 9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 33
10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . 36 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.1. Normative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 37 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37
C.1. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 37 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 38
C.2. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 37 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38
C.3. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 37 C.1. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 38
C.4. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37 C.2. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 38
C.5. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 37 C.3. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 38
C.6. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 37 C.4. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 38
C.7. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 37 C.5. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 38
C.8. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 38 C.6. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 38
C.9. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 38 C.7. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 C.8. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 39
C.9. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 39
C.10. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document describes how QUIC [QUIC-TRANSPORT] is secured using This document describes how QUIC [QUIC-TRANSPORT] is secured using
Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides
critical latency improvements for connection establishment over critical latency improvements for connection establishment over
previous versions. Absent packet loss, most new connections can be previous versions. Absent packet loss, most new connections can be
established and secured within a single round trip; on subsequent established and secured within a single round trip; on subsequent
connections between the same client and server, the client can often connections between the same client and server, the client can often
send application data immediately, that is, using a zero round trip send application data immediately, that is, using a zero round trip
skipping to change at page 12, line 4 skipping to change at page 12, line 20
TLS produces handshake octets. TLS produces handshake octets.
When TLS completed its handshake, 1-RTT keys can be provided to QUIC. When TLS completed its handshake, 1-RTT keys can be provided to QUIC.
On both client and server, this occurs after sending the TLS Finished On both client and server, this occurs after sending the TLS Finished
message. message.
This ordering means that there could be frames that carry TLS This ordering means that there could be frames that carry TLS
handshake messages ready to send at the same time that application handshake messages ready to send at the same time that application
data is available. An implementation MUST ensure that TLS handshake data is available. An implementation MUST ensure that TLS handshake
messages are always sent in packets protected with handshake keys messages are always sent in packets protected with handshake keys
(see Section 5.2.1). Separate packets are required for data that (see Section 5.2.2). Separate packets are required for data that
needs protection from 1-RTT keys. needs protection from 1-RTT keys.
If 0-RTT is possible, it is ready after the client sends a TLS If 0-RTT is possible, it is ready after the client sends a TLS
ClientHello message or the server receives that message. After ClientHello message or the server receives that message. After
providing a QUIC client with the first handshake octets, the TLS providing a QUIC client with the first handshake octets, the TLS
stack might signal that 0-RTT keys are ready. On the server, after stack might signal that 0-RTT keys are ready. On the server, after
receiving handshake octets that contain a ClientHello message, a TLS receiving handshake octets that contain a ClientHello message, a TLS
server might signal that 0-RTT keys are available. server might signal that 0-RTT keys are available.
1-RTT keys are used for packets in both directions. 0-RTT keys are 1-RTT keys are used for packets in both directions. 0-RTT keys are
skipping to change at page 15, line 4 skipping to change at page 15, line 29
match the AEAD negotiated by TLS. match the AEAD negotiated by TLS.
For packets other than any handshake packets (see Section 6.1), once For packets other than any handshake packets (see Section 6.1), once
a change of keys has been made, packets with higher packet numbers a change of keys has been made, packets with higher packet numbers
MUST be sent with the new keying material. The KEY_PHASE bit on MUST be sent with the new keying material. The KEY_PHASE bit on
these packets is inverted each time new keys are installed to signal these packets is inverted each time new keys are installed to signal
the use of the new keys to the recipient (see Section 6 for details). the use of the new keys to the recipient (see Section 6 for details).
An endpoint retransmits stream data in a new packet. New packets An endpoint retransmits stream data in a new packet. New packets
have new packet numbers and use the latest packet protection keys. have new packet numbers and use the latest packet protection keys.
This simplifies key management when there are key updates (see This simplifies key management when there are key updates (see
Section 6.2). Section 6.2).
5.2. QUIC Key Expansion 5.2. QUIC Key Expansion
QUIC uses a system of packet protection secrets, keys and IVs that QUIC uses a system of packet protection secrets, keys and IVs that
are modelled on the system used in TLS [TLS13]. The secrets that are modelled on the system used in TLS [TLS13]. The secrets that
QUIC uses as the basis of its key schedule are obtained using TLS QUIC uses as the basis of its key schedule are obtained using TLS
exporters (see Section 7.5 of [TLS13]). exporters (see Section 7.5 of [TLS13]).
QUIC uses HKDF with the same hash function negotiated by TLS for key 5.2.1. QHKDF-Expand
derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256,
the SHA-256 hash function is used.
5.2.1. Handshake Secrets QUIC uses the Hash-based Key Derivation Function (HKDF) [HKDF] with
the same hash function negotiated by TLS for key derivation. For
example, if TLS is using the TLS_AES_128_GCM_SHA256, the SHA-256 hash
function is used.
Packets that carry the TLS handshake (Initial, Retry, and Handshake) Most key derivations in this document use the QHKDF-Expand function,
are protected with secrets derived from the connection ID used in the which uses the HKDF expand function and is modelled on the HKDF-
client's Initial packet. Specifically: Expand-Label function from TLS 1.3 (see Section 7.1 of [TLS13]).
QHKDF-Expand differs from HKDF-Expand-Label in that it uses a
different base label and omits the Context argument.
quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639 QHKDF-Expand(Secret, Label, Length) =
HKDF-Expand(Secret, QhkdfExpandInfo, Length)
handshake_secret = HKDF-Extract(quic_version_1_salt, The HKDF-Expand function used by QHKDF-Expand uses the PRF hash
client_connection_id) function negotiated by TLS, except for handshake secrets and keys
derived from them (see Section 5.2.2).
client_handshake_secret = Where the "info" parameter of HKDF-Expand is an encoded
QHKDF-Expand(handshake_secret, "client hs", Hash.length) "QhkdfExpandInfo" structure:
server_handshake_secret =
QHKDF-Expand(handshake_secret, "server hs", Hash.length)
The HKDF for the handshake secrets and keys derived from them uses struct {
the SHA-256 hash function [FIPS180]. uint16 length = Length;
opaque label<6..255> = "QUIC " + Label;
} QhkdfExpandInfo;
The salt value is a 20 octet sequence shown in the figure in For example, assuming a hash function with a 32 octet output,
derivation for a client packet protection key would use HKDF-Expand
with an "info" parameter of 0x00200851554943206b6579.
5.2.2. Handshake Secrets
Packets that carry the TLS handshake (Initial, Retry, and Handshake)
are protected with a secret derived from the connection ID used in
the client's Initial packet. Specifically:
handshake_salt = 0x9c108f98520a5c5c32968e950e8a2c5fe06d6c38
handshake_secret =
HKDF-Extract(handshake_salt, client_connection_id)
client_handshake_secret =
QHKDF-Expand(handshake_secret, "client hs", Hash.length)
server_handshake_secret =
QHKDF-Expand(handshake_secret, "server hs", Hash.length)
The hash function for HKDF when deriving handshake secrets and keys
is SHA-256 [FIPS180]. The connection ID used with QHKDF-Expand is
the connection ID chosen by the client.
The handshake salt is a 20 octet sequence shown in the figure in
hexadecimal notation. Future versions of QUIC SHOULD generate a new hexadecimal notation. Future versions of QUIC SHOULD generate a new
salt value, thus ensuring that the keys are different for each salt value, thus ensuring that the keys are different for each
version of QUIC. This prevents a middlebox that only recognizes one version of QUIC. This prevents a middlebox that only recognizes one
version of QUIC from seeing or modifying the contents of handshake version of QUIC from seeing or modifying the contents of handshake
packets from future versions. packets from future versions.
5.2.2. 0-RTT Secret 5.2.3. 0-RTT Secret
0-RTT keys are those keys that are used in resumed connections prior 0-RTT keys are those keys that are used in resumed connections prior
to the completion of the TLS handshake. Data sent using 0-RTT keys to the completion of the TLS handshake. Data sent using 0-RTT keys
might be replayed and so has some restrictions on its use, see might be replayed and so has some restrictions on its use, see
Section 8.2. 0-RTT keys are used after sending or receiving a Section 8.2. 0-RTT keys are used after sending or receiving a
ClientHello. ClientHello.
The secret is exported from TLS using the exporter label "EXPORTER- The secret is exported from TLS using the exporter label "EXPORTER-
QUIC 0rtt" and an empty context. The size of the secret MUST be the QUIC 0rtt" and an empty context. The size of the secret MUST be the
size of the hash output for the PRF hash function negotiated by TLS. size of the hash output for the PRF hash function negotiated by TLS.
This uses the TLS early_exporter_secret. The QUIC 0-RTT secret is This uses the TLS early_exporter_secret. The QUIC 0-RTT secret is
only used for protection of packets sent by the client. only used for protection of packets sent by the client.
client_0rtt_secret client_0rtt_secret =
= TLS-Exporter("EXPORTER-QUIC 0rtt", "", Hash.length) TLS-Early-Exporter("EXPORTER-QUIC 0rtt", "", Hash.length)
5.2.3. 1-RTT Secrets 5.2.4. 1-RTT Secrets
1-RTT keys are used by both client and server after the TLS handshake 1-RTT keys are used by both client and server after the TLS handshake
completes. There are two secrets used at any time: one is used to completes. There are two secrets used at any time: one is used to
derive packet protection keys for packets sent by the client, the derive packet protection keys for packets sent by the client, the
other for packet protection keys on packets sent by the server. other for packet protection keys on packets sent by the server.
The initial client packet protection secret is exported from TLS The initial client packet protection secret is exported from TLS
using the exporter label "EXPORTER-QUIC client 1rtt"; the initial using the exporter label "EXPORTER-QUIC client 1rtt"; the initial
server packet protection secret uses the exporter label "EXPORTER- server packet protection secret uses the exporter label "EXPORTER-
QUIC server 1rtt". Both exporters use an empty context. The size of QUIC server 1rtt". Both exporters use an empty context. The size of
the secret MUST be the size of the hash output for the PRF hash the secret MUST be the size of the hash output for the PRF hash
function negotiated by TLS. function negotiated by TLS.
client_pp_secret_0 = client_pp_secret_0 =
TLS-Exporter("EXPORTER-QUIC client 1rtt", "", Hash.length) TLS-Exporter("EXPORTER-QUIC client 1rtt", "", Hash.length)
server_pp_secret_0 = server_pp_secret_0 =
TLS-Exporter("EXPORTER-QUIC server 1rtt", "", Hash.length) TLS-Exporter("EXPORTER-QUIC server 1rtt", "", Hash.length)
These secrets are used to derive the initial client and server packet These secrets are used to derive the initial client and server packet
protection keys. protection keys.
After a key update (see Section 6.2), these secrets are updated using 5.2.5. Updating 1-RTT Secrets
the QHKDF-Expand function. The QHKDF-Expand function is similar in
definition to HKDF-Expand-Label defined in Section 7.1 of [TLS13], After a key update (see Section 6.2), the 1-RTT secrets are updated
but it has a different base label and omits the hash argument. using QHKDF-Expand. Updated secrets are derived from the existing
QHKDF-Expand uses the PRF hash function negotiated by TLS. The packet protection secret. A Label parameter of "client 1rtt" is used
replacement secret is derived using the existing Secret, a Label of for the client secret and "server 1rtt" for the server. The Length
"client 1rtt" for the client and "server 1rtt" for the server, and is the same as the native output of the PRF hash function.
the same output Length as the PRF hash function selected by TLS.
client_pp_secret_<N+1> = client_pp_secret_<N+1> =
QHKDF-Expand(client_pp_secret_<N>, "client 1rtt", Hash.length) QHKDF-Update(client_pp_secret_<N>, "client 1rtt", Hash.length)
server_pp_secret_<N+1> = server_pp_secret_<N+1> =
QHKDF-Expand(server_pp_secret_<N>, "server 1rtt", Hash.length) QHKDF-Update(server_pp_secret_<N>, "server 1rtt", Hash.length)
This allows for a succession of new secrets to be created as needed. This allows for a succession of new secrets to be created as needed.
HKDF-Expand-Label uses HKDF-Expand [RFC5869] as shown: 5.2.6. Packet Protection Keys
QHKDF-Expand(Secret, Label, Length) =
HKDF-Expand(Secret, QuicHkdfLabel, Length)
Where the info parameter, QuicHkdfLabel, is specified as:
struct {
uint16 length = Length;
opaque label<6..255> = "QUIC " + Label;
uint8 hashLength = 0;
} QuicHkdfLabel;
For example, the client packet protection secret uses an info
parameter of:
info = (HashLen / 256) || (HashLen % 256) || 0x1f ||
"QUIC client 1rtt" || 0x00
5.2.4. Packet Protection Key and IV
The complete key expansion uses an identical process for key The complete key expansion uses a similar process for key expansion
expansion as defined in Section 7.3 of [TLS13], using different to that defined in Section 7.3 of [TLS13], using QHKDF-Expand in
values for the input secret and labels. QUIC uses the AEAD function place of HKDF-Expand-Label. QUIC uses the AEAD function negotiated
negotiated by TLS. by TLS.
The packet protection key and IV used to protect the 0-RTT packets The packet protection key and IV used to protect the 0-RTT packets
sent by a client are derived from the QUIC 0-RTT secret. The packet sent by a client are derived from the QUIC 0-RTT secret. The packet
protection keys and IVs for 1-RTT packets sent by the client and protection keys and IVs for 1-RTT packets sent by the client and
server are derived from the current generation of client and server server are derived from the current generation of client and server
1-RTT secrets (client_pp_secret_<i> and server_pp_secret_<i>) 1-RTT secrets (client_pp_secret_<i> and server_pp_secret_<i>)
respectively. The length of the output is determined by the respectively.
requirements of the AEAD function selected by TLS. All ciphersuites
currently used for QUIC have a 16-byte authentication tag and produce The length of the QHKDF-Expand output is determined by the
an ouput 16 bytes larger than their input. The key length is the requirements of the AEAD function selected by TLS. The key length is
AEAD key size. As defined in Section 5.3 of [TLS13], the IV length the AEAD key size. As defined in Section 5.3 of [TLS13], the IV
is the larger of 8 or N_MIN (see Section 4 of [AEAD]; all length is the larger of 8 or N_MIN (see Section 4 of [AEAD]; all
ciphersuites defined in [TLS13] have N_MIN set to 12). For any ciphersuites defined in [TLS13] have N_MIN set to 12).
secret S, the corresponding key and IV are derived as shown below:
For any secret S, the AEAD key uses a label of "key", and the IV uses
a label of "iv":
key = QHKDF-Expand(S, "key", key_length) key = QHKDF-Expand(S, "key", key_length)
iv = QHKDF-Expand(S, "iv", iv_length) iv = QHKDF-Expand(S, "iv", iv_length)
The QUIC record protection initially starts without keying material. The QUIC record protection initially starts with keying material
When the TLS state machine reports that the ClientHello has been derived from handshake keys. For a client, when the TLS state
sent, the 0-RTT keys can be generated and installed for writing. machine reports that the ClientHello has been sent, 0-RTT keys can be
When the TLS state machine reports completion of the handshake, the generated and installed for writing, if 0-RTT is available. Finally,
1-RTT keys can be generated and installed for writing. the TLS state machine reports completion of the handshake and 1-RTT
keys can be generated and installed for writing.
5.3. QUIC AEAD Usage 5.3. QUIC AEAD Usage
The Authentication Encryption with Associated Data (AEAD) [AEAD] The Authentication Encryption with Associated Data (AEAD) [AEAD]
function used for QUIC packet protection is AEAD that is negotiated function used for QUIC packet protection is AEAD that is negotiated
for use with the TLS connection. For example, if TLS is using the for use with the TLS connection. For example, if TLS is using the
TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used.
All QUIC packets other than Version Negotiation and Stateless Reset All QUIC packets other than Version Negotiation and Stateless Reset
packets are protected with an AEAD algorithm [AEAD]. Prior to packets are protected with an AEAD algorithm [AEAD]. Prior to
establishing a shared secret, packets are protected with establishing a shared secret, packets are protected with
AEAD_AES_128_GCM and a key derived from the client's connection ID AEAD_AES_128_GCM and a key derived from the client's connection ID
(see Section 5.2.1). This provides protection against off-path (see Section 5.2.2). This provides protection against off-path
attackers and robustness against QUIC version unaware middleboxes, attackers and robustness against QUIC version unaware middleboxes,
but not against on-path attackers. but not against on-path attackers.
All ciphersuites currently defined for TLS 1.3 - and therefore QUIC -
have a 16-byte authentication tag and produce an output 16 bytes
larger than their input.
Once TLS has provided a key, the contents of regular QUIC packets Once TLS has provided a key, the contents of regular QUIC packets
immediately after any TLS messages have been sent are protected by immediately after any TLS messages have been sent are protected by
the AEAD selected by TLS. the AEAD selected by TLS.
The key, K, is either the client packet protection key The key, K, is either the client packet protection key
(client_pp_key_<i>) or the server packet protection key (client_pp_key_<i>) or the server packet protection key
(server_pp_key_<i>), derived as defined in Section 5.2. (server_pp_key_<i>), derived as defined in Section 5.2.
The nonce, N, is formed by combining the packet protection IV (either The nonce, N, is formed by combining the packet protection IV (either
client_pp_iv_<i> or server_pp_iv_<i>) with the packet number. The 64 client_pp_iv_<i> or server_pp_iv_<i>) with the packet number. The 64
skipping to change at page 19, line 10 skipping to change at page 20, line 6
compromise of the current traffic keys does not allow an attacker to compromise of the current traffic keys does not allow an attacker to
truncate the data that is sent after a key update by sending truncate the data that is sent after a key update by sending
additional packets under the old key (causing new packets to be additional packets under the old key (causing new packets to be
discarded). discarded).
QUIC does not assume a reliable transport and is required to handle QUIC does not assume a reliable transport and is required to handle
attacks where packets are dropped in other ways. QUIC is therefore attacks where packets are dropped in other ways. QUIC is therefore
not affected by this form of truncation. not affected by this form of truncation.
The QUIC packet number is not reset and it is not permitted to go The QUIC packet number is not reset and it is not permitted to go
higher than its maximum value of 2^64-1. This establishes a hard higher than its maximum value of 2^62-1. This establishes a hard
limit on the number of packets that can be sent. limit on the number of packets that can be sent.
Some AEAD functions have limits for how many packets can be encrypted Some AEAD functions have limits for how many packets can be encrypted
under the same key and IV (see for example [AEBounds]). This might under the same key and IV (see for example [AEBounds]). This might
be lower than the packet number limit. An endpoint MUST initiate a be lower than the packet number limit. An endpoint MUST initiate a
key update (Section 6.2) prior to exceeding any limit set for the key update (Section 6.2) prior to exceeding any limit set for the
AEAD that is in use. AEAD that is in use.
TLS maintains a separate sequence number that is used for record TLS maintains a separate sequence number that is used for record
protection on the connection that is hosted on stream 0. This protection on the connection that is hosted on stream 0. This
skipping to change at page 20, line 27 skipping to change at page 21, line 24
header. header.
Transitions between keys during the handshake are complicated by the Transitions between keys during the handshake are complicated by the
need to ensure that TLS handshake messages are sent with the correct need to ensure that TLS handshake messages are sent with the correct
packet protection. packet protection.
6.1. Packet Protection for the TLS Handshake 6.1. Packet Protection for the TLS Handshake
The initial exchange of packets that carry the TLS handshake are The initial exchange of packets that carry the TLS handshake are
AEAD-protected using the handshake secrets generated as described in AEAD-protected using the handshake secrets generated as described in
Section 5.2.1. All TLS handshake messages up to the TLS Finished Section 5.2.2. All TLS handshake messages up to the TLS Finished
message sent by either endpoint use packets protected with handshake message sent by either endpoint use packets protected with handshake
keys. keys.
Any TLS handshake messages that are sent after completing the TLS Any TLS handshake messages that are sent after completing the TLS
handshake do not need special packet protection rules. Packets handshake do not need special packet protection rules. Packets
containing these messages use the packet protection keys that are containing these messages use the packet protection keys that are
current at the time of sending (or retransmission). current at the time of sending (or retransmission).
Like the client, a server MUST send retransmissions of its Like the client, a server MUST send retransmissions of its
unprotected handshake messages or acknowledgments for unprotected unprotected handshake messages or acknowledgments for unprotected
skipping to change at page 21, line 43 skipping to change at page 22, line 43
Even though newer keys could be available when retransmitting, Even though newer keys could be available when retransmitting,
retransmissions of these handshake messages MUST be sent in packets retransmissions of these handshake messages MUST be sent in packets
protected with handshake keys. An endpoint MUST generate ACK frames protected with handshake keys. An endpoint MUST generate ACK frames
for these messages and send them in packets protected with handshake for these messages and send them in packets protected with handshake
keys. keys.
A HelloRetryRequest handshake message might be used to reject an A HelloRetryRequest handshake message might be used to reject an
initial ClientHello. A HelloRetryRequest handshake message is sent initial ClientHello. A HelloRetryRequest handshake message is sent
in a Retry packet; any second ClientHello that is sent in response in a Retry packet; any second ClientHello that is sent in response
uses a Initial packet type. These packets are only protected with a uses a Initial packet type. These packets are only protected with a
predictable key (see Section 5.2.1). This is natural, because no predictable key (see Section 5.2.2). This is natural, because no
shared secret will be available when these messages need to be sent. shared secret will be available when these messages need to be sent.
Upon receipt of a HelloRetryRequest, a client SHOULD cease any Upon receipt of a HelloRetryRequest, a client SHOULD cease any
transmission of 0-RTT data; 0-RTT data will only be discarded by any transmission of 0-RTT data; 0-RTT data will only be discarded by any
server that sends a HelloRetryRequest. server that sends a HelloRetryRequest.
The packet type ensures that protected packets are clearly The packet type ensures that protected packets are clearly
distinguished from unprotected packets. Loss or reordering might distinguished from unprotected packets. Loss or reordering might
cause unprotected packets to arrive once 1-RTT keys are in use, cause unprotected packets to arrive once 1-RTT keys are in use,
unprotected packets are easily distinguished from 1-RTT packets using unprotected packets are easily distinguished from 1-RTT packets using
the packet type. the packet type.
skipping to change at page 29, line 18 skipping to change at page 30, line 18
Similarly, there is no need to increase the number of allowed streams Similarly, there is no need to increase the number of allowed streams
until the handshake completes. until the handshake completes.
8.1.4. Handshake Failures 8.1.4. Handshake Failures
The "CONNECTION_CLOSE" frame MAY be sent by either endpoint in a The "CONNECTION_CLOSE" frame MAY be sent by either endpoint in a
Handshake packet. This allows an endpoint to signal a fatal error Handshake packet. This allows an endpoint to signal a fatal error
with connection establishment. A "STREAM" frame carrying a TLS alert with connection establishment. A "STREAM" frame carrying a TLS alert
MAY be included in the same packet. MAY be included in the same packet.
8.1.5. Denial of Service with Unprotected Packets 8.1.5. Address Verification
In order to perform source-address verification before the handshake
is complete, "PATH_CHALLENGE" and "PATH_RESPONSE" frames MAY be
exchanged unprotected.
8.1.6. Denial of Service with Unprotected Packets
Accepting unprotected - specifically unauthenticated - packets Accepting unprotected - specifically unauthenticated - packets
presents a denial of service risk to endpoints. An attacker that is presents a denial of service risk to endpoints. An attacker that is
able to inject unprotected packets can cause a recipient to drop even able to inject unprotected packets can cause a recipient to drop even
protected packets with a matching sequence number. The spurious protected packets with a matching sequence number. The spurious
packet shadows the genuine packet, causing the genuine packet to be packet shadows the genuine packet, causing the genuine packet to be
ignored as redundant. ignored as redundant.
Once the TLS handshake is complete, both peers MUST ignore Once the TLS handshake is complete, both peers MUST ignore
unprotected packets. From that point onward, unprotected messages unprotected packets. From that point onward, unprotected messages
skipping to change at page 34, line 23 skipping to change at page 35, line 28
This document does not create any new IANA registries, but it This document does not create any new IANA registries, but it
registers the values in the following registries: registers the values in the following registries:
o QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to o QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to
register the three error codes found in Section 11, these are register the three error codes found in Section 11, these are
summarized in Table 1. summarized in Table 1.
o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register
the quic_transport_parameters extension found in Section 9.2. the quic_transport_parameters extension found in Section 9.2.
Assigning 26 to the extension would be greatly appreciated. The Assigning 26 to the extension would be greatly appreciated. The
Recommended column is to be marked Yes. Recommended column is to be marked Yes. The TLS 1.3 Column is to
include CH and EE.
o TLS Exporter Label Registry [TLS-REGISTRIES] - IANA is requested o TLS Exporter Label Registry [TLS-REGISTRIES] - IANA is requested
to register "EXPORTER-QUIC 0-RTT Secret" from Section 5.2.2; to register "EXPORTER-QUIC 0rtt" from Section 5.2.3; "EXPORTER-
"EXPORTER-QUIC client 1-RTT Secret" and "EXPORTER-QUIC server QUIC client 1rtt" and "EXPORTER-QUIC server 1-RTT" from
1-RTT Secret" from Section 5.2.3; "EXPORTER-QUIC Packet Number Section 5.2.4. The DTLS column is to be marked No. The
Secret" Section 5.6. The DTLS column is to be marked No. The
Recommended column is to be marked Yes. Recommended column is to be marked Yes.
+-------+---------------------------+---------------+---------------+ +-------+---------------------------+---------------+---------------+
| Value | Error | Description | Specification | | Value | Error | Description | Specification |
+-------+---------------------------+---------------+---------------+ +-------+---------------------------+---------------+---------------+
| 0x201 | TLS_HANDSHAKE_FAILED | TLS handshake | Section 11 | | 0x201 | TLS_HANDSHAKE_FAILED | TLS handshake | Section 11 |
| | | failure | | | | | failure | |
| | | | | | | | | |
| 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 | | 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 |
| | | alert | | | | | alert | |
skipping to change at page 35, line 4 skipping to change at page 36, line 6
| 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 | | 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 |
| | | alert | | | | | alert | |
| | | | | | | | | |
| 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS | Section 11 | | 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS | Section 11 |
| | | alert | | | | | alert | |
+-------+---------------------------+---------------+---------------+ +-------+---------------------------+---------------+---------------+
Table 1: QUIC Transport Error Codes for TLS Table 1: QUIC Transport Error Codes for TLS
13. References 13. References
13.1. Normative References 13.1. Normative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[FIPS180] Department of Commerce, National., "NIST FIPS 180-4, [FIPS180] Department of Commerce, National., "NIST FIPS 180-4,
Secure Hash Standard", March 2012, Secure Hash Standard", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[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-09 (work in progress), January 2018. transport-10 (work in progress), March 2018.
[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>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[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>.
[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>.
[TLS-REGISTRIES] [TLS-REGISTRIES]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", draft-ietf-tls-iana-registry-updates-03 (work and DTLS", draft-ietf-tls-iana-registry-updates-04 (work
in progress), January 2018. in progress), February 2018.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-23 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
January 2018. July 2017.
13.2. Informative References 13.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>.
[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-09 (work in progress), January QUIC", draft-ietf-quic-http-10 (work in progress), March
2018. 2018.
[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-09 (work and Congestion Control", draft-ietf-quic-recovery-10 (work
in progress), January 2018. in progress), March 2018.
[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 37, line 18 skipping to change at page 38, line 18
Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric
Rescorla, Ian Swett, and many others. Rescorla, Ian Swett, and many others.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-tls-08 C.1. Since draft-ietf-quic-tls-09
o Cleaned up key schedule and updated the salt used for handshake
packet protection (#1077)
C.2. Since draft-ietf-quic-tls-08
o Specify value for max_early_data_size to enable 0-RTT (#942) o Specify value for max_early_data_size to enable 0-RTT (#942)
o Update key derivation function (#1003, #1004) o Update key derivation function (#1003, #1004)
C.2. Since draft-ietf-quic-tls-07 C.3. Since draft-ietf-quic-tls-07
o Handshake errors can be reported with CONNECTION_CLOSE (#608, o Handshake errors can be reported with CONNECTION_CLOSE (#608,
#891) #891)
C.3. Since draft-ietf-quic-tls-05 C.4. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
C.4. Since draft-ietf-quic-tls-04 C.5. Since draft-ietf-quic-tls-04
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.5. Since draft-ietf-quic-tls-03 C.6. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
C.6. Since draft-ietf-quic-tls-02 C.7. Since draft-ietf-quic-tls-02
o Updates to match changes in transport draft o Updates to match changes in transport draft
C.7. Since draft-ietf-quic-tls-01 C.8. Since draft-ietf-quic-tls-01
o Use TLS alerts to signal TLS errors (#272, #374) o Use TLS alerts to signal TLS errors (#272, #374)
o Require ClientHello to fit in a single packet (#338) o Require ClientHello to fit in a single packet (#338)
o The second client handshake flight is now sent in the clear (#262, o The second client handshake flight is now sent in the clear (#262,
#337) #337)
o The QUIC header is included as AEAD Associated Data (#226, #243, o The QUIC header is included as AEAD Associated Data (#226, #243,
#302) #302)
skipping to change at page 38, line 21 skipping to change at page 39, line 30
o Require at least TLS 1.3 (#138) o Require at least TLS 1.3 (#138)
o Define transport parameters as a TLS extension (#122) o Define transport parameters as a TLS extension (#122)
o Define handling for protected packets before the handshake o Define handling for protected packets before the handshake
completes (#39) completes (#39)
o Decouple QUIC version and ALPN (#12) o Decouple QUIC version and ALPN (#12)
C.8. Since draft-ietf-quic-tls-00 C.9. Since draft-ietf-quic-tls-00
o Changed bit used to signal key phase o Changed bit used to signal key phase
o Updated key phase markings during the handshake o Updated key phase markings during the handshake
o Added TLS interface requirements section o Added TLS interface requirements section
o Moved to use of TLS exporters for key derivation o Moved to use of TLS exporters for key derivation
o Moved TLS error code definitions into this document o Moved TLS error code definitions into this document
C.9. Since draft-thomson-quic-tls-01 C.10. Since draft-thomson-quic-tls-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added status note o Added status note
Authors' Addresses Authors' Addresses
Martin Thomson (editor) Martin Thomson (editor)
 End of changes. 57 change blocks. 
170 lines changed or deleted 201 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/