draft-ietf-quic-tls-12.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: November 23, 2018 sn3rd Expires: December 15, 2018 sn3rd
May 22, 2018 June 13, 2018
Using Transport Layer Security (TLS) to Secure QUIC Using Transport Layer Security (TLS) to Secure QUIC
draft-ietf-quic-tls-12 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 November 23, 2018. This Internet-Draft will expire on December 15, 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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
5.3.2. Handshake Secrets . . . . . . . . . . . . . . . . . . 17 5.3.2. Handshake Secrets . . . . . . . . . . . . . . . . . . 17
5.3.3. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 17 5.3.3. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 17
5.3.4. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 18 5.3.4. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 18
5.3.5. Updating 1-RTT Secrets . . . . . . . . . . . . . . . 18 5.3.5. Updating 1-RTT Secrets . . . . . . . . . . . . . . . 18
5.3.6. Packet Protection Keys . . . . . . . . . . . . . . . 18 5.3.6. Packet Protection Keys . . . . . . . . . . . . . . . 18
5.4. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 19 5.4. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 19
5.5. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 20 5.5. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 20
5.6. Packet Number Protection . . . . . . . . . . . . . . . . 21 5.6. Packet Number Protection . . . . . . . . . . . . . . . . 21
5.6.1. AES-Based Packet Number Protection . . . . . . . . . 22 5.6.1. AES-Based Packet Number Protection . . . . . . . . . 22
5.6.2. ChaCha20-Based Packet Number Protection . . . . . . . 22 5.6.2. ChaCha20-Based Packet Number Protection . . . . . . . 22
5.7. Receiving Protected Packets . . . . . . . . . . . . . . . 22 5.7. Receiving Protected Packets . . . . . . . . . . . . . . . 23
6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Packet Protection for the TLS Handshake . . . . . . . . . 23 6.1. Packet Protection for the TLS Handshake . . . . . . . . . 24
6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 24 6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 24
6.1.2. Retransmission and Acknowledgment of Unprotected 6.1.2. Retransmission and Acknowledgment of Unprotected
Packets . . . . . . . . . . . . . . . . . . . . . . . 24 Packets . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 25 6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 26
7. Client Address Validation . . . . . . . . . . . . . . . . . . 27 7. Client Address Validation . . . . . . . . . . . . . . . . . . 27
7.1. HelloRetryRequest Address Validation . . . . . . . . . . 27 7.1. HelloRetryRequest Address Validation . . . . . . . . . . 27
7.1.1. Stateless Address Validation . . . . . . . . . . . . 28 7.1.1. Stateless Address Validation . . . . . . . . . . . . 28
7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 28 7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 28
7.2. NewSessionTicket Address Validation . . . . . . . . . . . 29 7.2. NewSessionTicket Address Validation . . . . . . . . . . . 29
7.3. Address Validation Token Integrity . . . . . . . . . . . 29 7.3. Address Validation Token Integrity . . . . . . . . . . . 30
8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 29 8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 30
8.1. Unprotected Packets Prior to Handshake Completion . . . . 30 8.1. Unprotected Packets Prior to Handshake Completion . . . . 31
8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 31 8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 31
8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 31 8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 31
8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 31 8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 32
8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 32 8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 32
8.1.5. Address Verification . . . . . . . . . . . . . . . . 32 8.1.5. Address Verification . . . . . . . . . . . . . . . . 32
8.1.6. Denial of Service with Unprotected Packets . . . . . 32 8.1.6. Denial of Service with Unprotected Packets . . . . . 33
8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 33 8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 33
8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 33 8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 34
9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 34 9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 34
9.1. Protocol and Version Negotiation . . . . . . . . . . . . 34 9.1. Protocol and Version Negotiation . . . . . . . . . . . . 34
9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 34 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 35 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 36
10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 35 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 36
10.3. Packet Number Protection Analysis . . . . . . . . . . . 36 10.3. Packet Number Protection Analysis . . . . . . . . . . . 36
11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.1. Normative References . . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 39 13.2. Informative References . . . . . . . . . . . . . . . . . 40
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40 A.1. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 41
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40 A.2. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 41
C.1. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 41 A.3. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 41
C.2. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 41 A.4. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 41
C.3. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 41 A.5. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 41
C.4. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 41 A.6. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 41
C.5. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 41 A.7. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 41
C.6. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 41 A.8. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 42
C.7. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 41 A.9. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 42
C.8. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 41 A.10. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 42
C.9. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 41 A.11. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 42
C.10. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 42 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.11. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 42 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 19, line 18 skipping to change at page 19, line 18
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. respectively.
The length of the QHKDF-Expand output is determined by the The length of the QHKDF-Expand output is determined by the
requirements of the AEAD function selected by TLS. The key length is requirements of the AEAD function selected by TLS. The key length is
the AEAD key size. As defined in Section 5.3 of [TLS13], the IV the AEAD key size. As defined in Section 5.3 of [TLS13], the IV
length 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). ciphersuites defined in [TLS13] have N_MIN set to 12).
The size of the packet protection key is determined by the packet The size of the packet number protection key is determined by the
protection algorithm, see Section 5.6. packet number protection algorithm, see Section 5.6.
For any secret S, the AEAD key uses a label of "key", the IV uses a For any secret S, the AEAD key uses a label of "key", the IV uses a
label of "iv", packet number encryption uses a label of "pn": label of "iv", packet number encryption uses a label of "pn":
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)
pn_key = QHKDF-Expand(S, "pn", pn_key_length) pn_key = QHKDF-Expand(S, "pn", pn_key_length)
Separate keys are derived for packet protection by clients and Separate keys are derived for packet protection by clients and
servers. Each endpoint uses the packet protection key of its peer to servers. Each endpoint uses the packet protection key of its peer to
remove packet protection. For example, client packet protection keys remove packet protection. For example, client packet protection keys
and IVs - which are also used by the server to remove the protection and IVs - which are also used by the server to remove the protection
added by a client - for AEAD_AES_128_GCM are derived from 1-RTT added by a client - for AEAD_AES_128_GCM are derived from 1-RTT
secrets as follows: secrets as follows:
client_pp_key<i> = QHKDF-Expand(client_pp_secret<i>, "key", 16) client_pp_key<i> = QHKDF-Expand(client_pp_secret<i>, "key", 16)
client_pp_iv<i> = QHKDF-Expand(client_pp_secret<i>, "iv", 12) client_pp_iv<i> = QHKDF-Expand(client_pp_secret<i>, "iv", 12)
client_pp_pn<i> = QHKDF-Expand(client_pp_secret<i>, "pn", 12) client_pp_pn<i> = QHKDF-Expand(client_pp_secret<i>, "pn", 16)
The QUIC packet protection initially starts with keying material The QUIC packet protection initially starts with keying material
derived from handshake keys. For a client, when the TLS state derived from handshake keys. For a client, when the TLS state
machine reports that the ClientHello has been sent, 0-RTT keys can be machine reports that the ClientHello has been sent, 0-RTT keys can be
generated and installed for writing, if 0-RTT is available. Finally, generated and installed for writing, if 0-RTT is available. Finally,
the TLS state machine reports completion of the handshake and 1-RTT the TLS state machine reports completion of the handshake and 1-RTT
keys can be generated and installed for writing. keys can be generated and installed for writing.
5.4. QUIC AEAD Usage 5.4. 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 the AEAD that is
for use with the TLS connection. For example, if TLS is using the negotiated for use with the TLS connection. For example, if TLS is
TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is
used.
QUIC packets are protected prior to applying packet number encryption QUIC packets are protected prior to applying packet number encryption
(Section 5.6). The unprotected packet number is part of the (Section 5.6). The unprotected packet number is part of the
associated data (A). When removing packet protection, an endpoint associated data (A). When removing packet protection, an endpoint
first removes the protection from the packet number. first removes the protection from the packet number.
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
skipping to change at page 21, line 27 skipping to change at page 21, line 27
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
sequence number is not visible to QUIC. sequence number is not visible to QUIC.
5.6. Packet Number Protection 5.6. Packet Number Protection
QUIC packets are protected using a key that is derived from the QUIC packet numbers are protected using a key that is derived from
current set of secrets. The key derived using the "pn" label is used the current set of secrets. The key derived using the "pn" label is
to protect the packet number from casual observation. The packet used to protect the packet number from casual observation. The
number protection algorithm depends on the negotiated AEAD. packet number protection algorithm depends on the negotiated AEAD.
Packet number protection is applied after packet protection is Packet number protection is applied after packet protection is
applied (see Section 5.4). The ciphertext of the packet is sampled applied (see Section 5.4). The ciphertext of the packet is sampled
and used as input to an encryption algorithm. and used as input to an encryption algorithm.
In sampling the packet ciphertext, the packet number length is In sampling the packet ciphertext, the packet number length is
assumed to be the smaller of the maximum possible packet number assumed to be 4 octets (its maximum possible encoded length), unless
encoding (4 octets), or the size of the protected packet minus the there is insufficient space in the packet for sampling. The sampled
minimum expansion for the AEAD. For example, the sampled ciphertext ciphertext starts after allowing for a 4 octet packet number unless
for a packet with a short header can be determined by: this would cause the sample to extend past the end of the packet. If
the sample would extend past the end of the packet, the end of the
packet is sampled.
"sample_offset = min(1 + connection_id_length + 4, packet_length - For example, the sampled ciphertext for a packet with a short header
aead_expansion) sample = can be determined by:
packet[sample_offset..sample_offset+sample_length]"
sample_offset = 1 + len(connection_id) + 4
if sample_offset + sample_length > packet_length then
sample_offset = packet_length - sample_length
sample = packet[sample_offset..sample_offset+sample_length]
A packet with a long header is sampled in the same way, noting that
multiple QUIC packets might be included in the same UDP datagram and
that each one is handled separately.
sample_offset = 6 + len(destination_connection_id) +
len(source_connection_id) +
len(payload_length) + 4
To ensure that this process does not sample the packet number, packet To ensure that this process does not sample the packet number, packet
number protection algorithms MUST NOT sample more ciphertext than the number protection algorithms MUST NOT sample more ciphertext than the
minimum expansion of the corresponding AEAD. minimum expansion of the corresponding AEAD.
Packet number protection is applied to the packet number encoded as Packet number protection is applied to the packet number encoded as
described in Section 4.8 of [QUIC-TRANSPORT]. Since the length of described in Section 4.8 of [QUIC-TRANSPORT]. Since the length of
the packet number is stored in the first octet of the encoded packet the packet number is stored in the first octet of the encoded packet
number, it may be necessary to progressively decrypt the packet number, it may be necessary to progressively decrypt the packet
number. number.
skipping to change at page 35, line 6 skipping to change at page 35, line 27
9.2. QUIC Transport Parameters Extension 9.2. QUIC Transport Parameters Extension
QUIC transport parameters are carried in a TLS extension. Different QUIC transport parameters are carried in a TLS extension. Different
versions of QUIC might define a different format for this struct. versions of QUIC might define a different format for this struct.
Including transport parameters in the TLS handshake provides Including transport parameters in the TLS handshake provides
integrity protection for these values. integrity protection for these values.
enum { enum {
quic_transport_parameters(26), (65535) quic_transport_parameters(0xffa5), (65535)
} ExtensionType; } ExtensionType;
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in contains a value that is defined by the version of QUIC that is in
use. The quic_transport_parameters extension carries a use. The quic_transport_parameters extension carries a
TransportParameters when the version of QUIC defined in TransportParameters 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. and the EncryptedExtensions messages during the handshake.
skipping to change at page 36, line 23 skipping to change at page 36, line 49
endpoints MUST NOT send TLS application data records. Receiving TLS endpoints MUST NOT send TLS application data records. Receiving TLS
application data MUST be treated as a connection error of type application data MUST be treated as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
While there are legitimate uses for some redundant packets, While there are legitimate uses for some redundant packets,
implementations SHOULD track redundant packets and treat excessive implementations SHOULD track redundant packets and treat excessive
volumes of any non-productive packets as indicative of an attack. volumes of any non-productive packets as indicative of an attack.
10.3. Packet Number Protection Analysis 10.3. Packet Number Protection Analysis
Packet number protection relies the packet protection AEAD being a Packet number protection relies on the packet protection AEAD being a
pseudorandom function (PRF), which is not a property that AEAD pseudorandom function (PRF), which is not a property that AEAD
algorithms guarantee. Therefore, no strong assurances about the algorithms guarantee. Therefore, no strong assurances about the
general security of this mechanism can be shown in the general case. general security of this mechanism can be shown in the general case.
The AEAD algorithms described in this document are assumed to be The AEAD algorithms described in this document are assumed to be
PRFs. PRFs.
The packet number protection algorithms defined in this document take The packet number protection algorithms defined in this document take
the form: the form:
"encrypted_pn = packet_number XOR PRF(pn_key, sample)" encrypted_pn = packet_number XOR PRF(pn_key, sample)
This construction is secure against chosen plaintext attacks (IND- This construction is secure against chosen plaintext attacks (IND-
CPA) [IMC]. CPA) [IMC].
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 packet number protection. Protecting two different compromising packet number protection. Protecting two different
packet numbers with the same key and ciphertext sample reveals the packet numbers with the same key and ciphertext sample reveals the
exclusive OR of those packet numbers. Assuming that the AEAD acts as exclusive OR of those packet numbers. Assuming that the AEAD acts as
a PRF, if L bits are sampled, the odds of two ciphertext samples a PRF, if L bits are sampled, the odds of two ciphertext samples
being identical approach 2^(-L/2), that is, the birthday bound. For being identical approach 2^(-L/2), that is, the birthday bound. For
skipping to change at page 37, line 47 skipping to change at page 38, line 26
12. IANA Considerations 12. IANA Considerations
This document does not create any new IANA registries, but it This document does not create any new IANA registries, but it
registers the values in the following registries: registers the values in the following registries:
o 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. The
Assigning 26 to the extension would be greatly appreciated. The
Recommended column is to be marked Yes. The TLS 1.3 Column is to Recommended column is to be marked Yes. The TLS 1.3 Column is to
include CH and EE. 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 0rtt" from Section 5.3.3; "EXPORTER- to register "EXPORTER-QUIC 0rtt" from Section 5.3.3; "EXPORTER-
QUIC client 1rtt" and "EXPORTER-QUIC server 1-RTT" from QUIC client 1rtt" and "EXPORTER-QUIC server 1-RTT" from
Section 5.3.4. The DTLS column is to be marked No. The Section 5.3.4. The DTLS column is to be marked No. The
Recommended column is to be marked Yes. Recommended column is to be marked Yes.
+-------+---------------------------+---------------+---------------+ +-------+---------------------------+---------------+---------------+
skipping to change at page 38, line 50 skipping to change at page 39, line 29
<https://www.rfc-editor.org/info/rfc7539>. <https://www.rfc-editor.org/info/rfc7539>.
[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <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-12 (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>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] 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>.
skipping to change at page 39, line 28 skipping to change at page 40, line 6
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHA] Dang, Q., "Secure Hash Standard", National Institute of [SHA] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology report, Standards and Technology report,
DOI 10.6028/nist.fips.180-4, July 2015. DOI 10.6028/nist.fips.180-4, July 2015.
[TLS-REGISTRIES] [TLS-REGISTRIES]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS Salowey, J. and S. Turner, "IANA Registry Updates for
and DTLS", draft-ietf-tls-iana-registry-updates-04 (work Transport Layer Security (TLS) and Datagram Transport
in progress), February 2018. Layer Security (DTLS)", draft-ietf-tls-iana-registry-
updates-05 (work in progress), May 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-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
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>.
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern [IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269, Cryptography, Second Edition", ISBN 978-1466570269,
November 2014. November 2014.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-12 (work in progress). QUIC", draft-ietf-quic-http-latest (work in progress).
[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-12 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (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 40, line 33 skipping to change at page 41, line 13
<https://www.rfc-editor.org/info/rfc7924>. <https://www.rfc-editor.org/info/rfc7924>.
13.3. URIs 13.3. URIs
[1] https://mailarchive.ietf.org/arch/search/?email_list=quic [1] https://mailarchive.ietf.org/arch/search/?email_list=quic
[2] https://github.com/quicwg [2] https://github.com/quicwg
[3] https://github.com/quicwg/base-drafts/labels/-tls [3] https://github.com/quicwg/base-drafts/labels/-tls
Appendix A. Contributors Appendix A. Change Log
Ryan Hamilton was originally an author of this specification.
Appendix B. Acknowledgments
This document has benefited from input from Dragana Damjanovic,
Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric
Rescorla, Ian Swett, and many others.
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-10 A.1. Since draft-ietf-quic-tls-10
o No significant changes. o No significant changes.
C.2. Since draft-ietf-quic-tls-09 A.2. Since draft-ietf-quic-tls-09
o Cleaned up key schedule and updated the salt used for handshake o Cleaned up key schedule and updated the salt used for handshake
packet protection (#1077) packet protection (#1077)
C.3. Since draft-ietf-quic-tls-08 A.3. 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.4. Since draft-ietf-quic-tls-07 A.4. 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.5. Since draft-ietf-quic-tls-05 A.5. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
C.6. Since draft-ietf-quic-tls-04 A.6. 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.7. Since draft-ietf-quic-tls-03 A.7. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
C.8. Since draft-ietf-quic-tls-02 A.8. Since draft-ietf-quic-tls-02
o Updates to match changes in transport draft o Updates to match changes in transport draft
C.9. Since draft-ietf-quic-tls-01 A.9. 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 42, line 18 skipping to change at page 42, line 34
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.10. Since draft-ietf-quic-tls-00 A.10. 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.11. Since draft-thomson-quic-tls-01 A.11. Since draft-thomson-quic-tls-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added status note o Added status note
Acknowledgments
This document has benefited from input from Dragana Damjanovic,
Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric
Rescorla, Ian Swett, and many others.
Contributors
Ryan Hamilton was originally an author of this specification.
Authors' Addresses Authors' Addresses
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
Sean Turner (editor) Sean Turner (editor)
sn3rd sn3rd
 End of changes. 41 change blocks. 
88 lines changed or deleted 104 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/