draft-ietf-quic-tls-17.txt   draft-ietf-quic-tls-18.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: June 21, 2019 sn3rd Expires: July 27, 2019 sn3rd
December 18, 2018 January 23, 2019
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-17 draft-ietf-quic-tls-18
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 June 21, 2019. This Internet-Draft will expire on July 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 29 9.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 29
9.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 30 9.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 30
9.3. Header Protection Analysis . . . . . . . . . . . . . . . 30 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 30
9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 33
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Sample Initial Packet Protection . . . . . . . . . . 34
A.1. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 34 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.2. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 34 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 35
A.3. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 34 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 37
A.4. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 35 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38
A.5. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 35 B.1. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 38
A.6. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 35 B.2. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 38
A.7. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 35 B.3. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 39
A.8. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 35 B.4. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 39
A.9. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 35 B.5. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 39
A.10. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 35 B.6. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 39
A.11. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 36 B.7. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 39
A.12. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 36 B.8. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 40
A.13. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 36 B.9. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 40
A.14. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 36 B.10. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 40
A.15. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 37 B.11. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 40
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.12. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 40
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.13. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 B.14. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 40
B.15. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 41
B.16. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 15, line 13 skipping to change at page 15, line 13
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 (see
Section 4.6.2 of [TLS13]). Section 4.6.2 of [TLS13]).
4.5. Enabling 0-RTT 4.5. Enabling 0-RTT
In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket
message that contains the "max_early_data" extension with the value message that contains the "early_data" extension with a
0xffffffff; the amount of data which the client can send in 0-RTT is max_early_data_size of 0xffffffff; the amount of data which the
controlled by the "initial_max_data" transport parameter supplied by client can send in 0-RTT is controlled by the "initial_max_data"
the server. A client MUST treat receipt of a NewSessionTicket that transport parameter supplied by the server. A client MUST treat
contains a "max_early_data" extension with any other value as a receipt of a NewSessionTicket that contains an "early_data" extension
connection error of type PROTOCOL_VIOLATION. with any other value as a connection error of type
PROTOCOL_VIOLATION.
Early data within the TLS connection MUST NOT be used. As it is for 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 other TLS application data, a server MUST treat receiving early data
on the TLS connection as a connection error of type on the TLS connection as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
4.6. Rejecting 0-RTT 4.6. Rejecting 0-RTT
A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This
also prevents QUIC from sending 0-RTT data. A server will always also prevents QUIC from sending 0-RTT data. A server will always
skipping to change at page 16, line 51 skipping to change at page 17, line 5
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.
After all CRYPTO frames for a given encryption level have been sent After all CRYPTO frames for a given encryption level have been sent
and all expected CRYPTO frames received, and all the corresponding and all expected CRYPTO frames received, and all the corresponding
acknowledgments have been received or sent, an endpoint starts a acknowledgments have been received or sent, an endpoint starts a
timer. For 0-RTT keys, which do not carry CRYPTO frames, this timer timer. For 0-RTT keys, which do not carry CRYPTO frames, this timer
starts when the first packets protected with 1-RTT are sent or starts when the first packets protected with 1-RTT are sent or
received. To limit the effect of packet loss around a change in received. To limit the effect of packet loss around a change in
keys, endpoints MUST retain packet protection keys for that keys, endpoints MUST retain packet protection keys for that
encryption level for at least three times the current Retransmission encryption level for at least three times the current Probe Timeout
Timeout (RTO) interval as defined in [QUIC-RECOVERY]. Retaining keys (PTO) interval as defined in [QUIC-RECOVERY]. Retaining keys for
for this interval allows packets containing CRYPTO or ACK frames at this interval allows packets containing CRYPTO or ACK frames at that
that encryption level to be sent if packets are determined to be lost encryption level to be sent if packets are determined to be lost or
or new packets require acknowledgment. new packets require acknowledgment.
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.
Once this timer expires, an endpoint MUST NOT either accept or Once this timer expires, an endpoint MUST NOT either accept or
generate new packets using those packet protection keys. An endpoint generate new packets using those packet protection keys. An endpoint
can discard packet protection keys for that encryption level. can discard packet protection keys for that encryption level.
skipping to change at page 19, line 25 skipping to change at page 19, line 25
in hexadecimal notation. Future versions of QUIC SHOULD generate a in hexadecimal notation. Future versions of QUIC SHOULD generate a
new salt value, thus ensuring that the keys are different for each new 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.
The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
Initial packets even where the TLS versions offered do not include Initial packets even where the TLS versions offered do not include
TLS 1.3. TLS 1.3.
Appendix A contains test vectors for the initial packet encryption.
Note: The Destination Connection ID is of arbitrary length, and it Note: The Destination Connection ID is of arbitrary length, and it
could be zero length if the server sends a Retry packet with a could be zero length if the server sends a Retry packet with a
zero-length Source Connection ID field. In this case, the Initial zero-length Source Connection ID field. In this case, the Initial
keys provide no assurance to the client that the server received keys provide no assurance to the client that the server received
its packet; the client has to rely on the exchange that included its packet; the client has to rely on the exchange that included
the Retry packet for that property. the Retry packet for that property.
5.3. AEAD Usage 5.3. AEAD Usage
The Authentication Encryption with Associated Data (AEAD) [AEAD] The Authentication Encryption with Associated Data (AEAD) [AEAD]
skipping to change at page 20, line 15 skipping to change at page 20, line 17
QUIC can use any of the ciphersuites defined in [TLS13] with the QUIC can use any of the ciphersuites defined in [TLS13] with the
exception of TLS_AES_128_CCM_8_SHA256. The AEAD for that exception of TLS_AES_128_CCM_8_SHA256. The AEAD for that
ciphersuite, AEAD_AES_128_CCM_8 [CCM], does not produce a large ciphersuite, AEAD_AES_128_CCM_8 [CCM], does not produce a large
enough authentication tag for use with the header protection designs enough authentication tag for use with the header protection designs
provided (see Section 5.4). All other ciphersuites defined in provided (see Section 5.4). All other ciphersuites defined in
[TLS13] have a 16-byte authentication tag and produce an output 16 [TLS13] have a 16-byte authentication tag and produce an output 16
bytes larger than their input. bytes larger than their input.
The key and IV for the packet are computed as described in The key and IV for the packet are computed as described in
Section 5.1. The nonce, N, is formed by combining the packet Section 5.1. The nonce, N, is formed by combining the packet
protection IV with the packet number. The 64 bits of the protection IV with the packet number. The 62 bits of the
reconstructed QUIC packet number in network byte order are left- reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV. The exclusive OR of the padded with zeros to the size of the IV. The exclusive OR of the
padded packet number and the IV forms the AEAD nonce. padded packet number and the IV forms the AEAD nonce.
The associated data, A, for the AEAD is the contents of the QUIC The associated data, A, for the AEAD is the contents of the QUIC
header, starting from the flags byte in either the short or long header, starting from the flags byte in either the short or long
header, up to and including the unprotected packet number. header, up to and including the unprotected packet number.
The input plaintext, P, for the AEAD is the payload of the QUIC The input plaintext, P, for the AEAD is the payload of the QUIC
packet, as described in [QUIC-TRANSPORT]. packet, as described in [QUIC-TRANSPORT].
skipping to change at page 23, line 47 skipping to change at page 23, line 47
5.4.3. AES-Based Header Protection 5.4.3. AES-Based Header Protection
This section defines the packet protection algorithm for This section defines the packet protection algorithm for
AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and
AEAD_AES_256_CCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AEAD_AES_256_CCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit
AES [AES] in electronic code-book (ECB) mode. AEAD_AES_256_GCM, and AES [AES] in electronic code-book (ECB) mode. AEAD_AES_256_GCM, and
AEAD_AES_256_CCM use 256-bit AES in ECB mode. AEAD_AES_256_CCM use 256-bit AES in ECB mode.
This algorithm samples 16 bytes from the packet ciphertext. This This algorithm samples 16 bytes from the packet ciphertext. This
value is used as the counter input to AES-ECB. In pseudocode: value is used as the input to AES-ECB. In pseudocode:
mask = AES-ECB(pn_key, sample) mask = AES-ECB(hp_key, sample)
5.4.4. ChaCha20-Based Header Protection 5.4.4. ChaCha20-Based Header Protection
When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw
ChaCha20 function as defined in Section 2.4 of [CHACHA]. This uses a ChaCha20 function as defined in Section 2.4 of [CHACHA]. This uses a
256-bit key and 16 bytes sampled from the packet protection output. 256-bit key and 16 bytes sampled from the packet protection output.
The first 4 bytes of the sampled ciphertext are interpreted as a The first 4 bytes of the sampled ciphertext are interpreted as a
32-bit number in little-endian order and are used as the block count. 32-bit number in little-endian order and are used as the block count.
The remaining 12 bytes are interpreted as three concatenated 32-bit The remaining 12 bytes are interpreted as three concatenated 32-bit
numbers in little-endian order and used as the nonce. numbers in little-endian order and used as the nonce.
The encryption mask is produced by invoking ChaCha20 to protect 5 The encryption mask is produced by invoking ChaCha20 to protect 5
zero bytes. In pseudocode: zero bytes. In pseudocode:
counter = DecodeLE(sample[0..3]) counter = DecodeLE(sample[0..3])
nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15]) nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15])
mask = ChaCha20(pn_key, counter, nonce, {0,0,0,0,0}) mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})
5.5. Receiving Protected Packets 5.5. Receiving Protected Packets
Once an endpoint successfully receives a packet with a given packet Once an endpoint successfully receives a packet with a given packet
number, it MUST discard all packets in the same packet number space number, it MUST discard all packets in the same packet number space
with higher packet numbers if they cannot be successfully unprotected with higher packet numbers if they cannot be successfully unprotected
with either the same key, or - if there is a key update - the next with either the same key, or - if there is a key update - the next
packet protection key (see Section 6). Similarly, a packet that packet protection key (see Section 6). Similarly, a packet that
appears to trigger a key update, but cannot be unprotected appears to trigger a key update, but cannot be unprotected
successfully MUST be discarded. successfully MUST be discarded.
skipping to change at page 28, line 26 skipping to change at page 28, line 26
version of QUIC that is used prior to the completion of the version of QUIC that is used prior to the completion of the
handshake. However, this packet is not authenticated, enabling an handshake. However, this packet is not authenticated, enabling an
active attacker to force a version downgrade. active attacker to force a version downgrade.
To ensure that a QUIC version downgrade is not forced by an attacker, To ensure that a QUIC version downgrade is not forced by an attacker,
version information is copied into the TLS handshake, which provides version information is copied into the TLS handshake, which provides
integrity protection for the QUIC negotiation. This does not prevent integrity protection for the QUIC negotiation. This does not prevent
version downgrade prior to the completion of the handshake, though it version downgrade prior to the completion of the handshake, though it
means that a downgrade causes a handshake failure. means that a downgrade causes a handshake failure.
TLS uses Application Layer Protocol Negotiation (ALPN) [RFC7301] to QUIC requires that the cryptographic handshake provide authenticated
select an application protocol. The application-layer protocol MAY protocol negotiation. TLS uses Application Layer Protocol
restrict the QUIC versions that it can operate over. Servers MUST Negotiation (ALPN) [RFC7301] to select an application protocol.
select an application protocol compatible with the QUIC version that Unless another mechanism is used for agreeing on an application
the client has selected. protocol, endpoints MUST use ALPN for this purpose. When using ALPN,
endpoints MUST abort a connection if an application protocol is not
negotiated.
If the server cannot select a compatible combination of application An application-layer protocol MAY restrict the QUIC versions that it
can operate over. Servers MUST select an application protocol
compatible with the QUIC version that the client has selected. If
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 incompatible MUST abort a connection if the server picks an incompatible
combination of QUIC version and ALPN identifier. combination of QUIC version and ALPN identifier.
8.2. QUIC Transport Parameters Extension 8.2. QUIC Transport Parameters Extension
QUIC transport parameters are carried in a TLS extension. Different QUIC transport parameters are carried in a TLS extension. Different
versions of QUIC might define a different 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
skipping to change at page 30, line 40 skipping to change at page 30, line 44
Header protection relies on the packet protection AEAD being a Header 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 header protection algorithms defined in this document take the The header protection algorithms defined in this document take the
form: form:
protected_field = field XOR PRF(pn_key, sample) protected_field = field XOR PRF(hp_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 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
skipping to change at page 31, line 46 skipping to change at page 31, line 49
keys only include the ClientHello message and might therefore use the keys only include the ClientHello message and might therefore use the
same secrets. To avoid the possibility of cross-protocol key same secrets. To avoid the possibility of cross-protocol key
synchronization, additional measures are provided to improve key synchronization, additional measures are provided to improve key
separation. separation.
The QUIC packet protection keys and IVs are derived using a different The QUIC packet protection keys and IVs are derived using a different
label than the equivalent keys in TLS. label than the equivalent keys in TLS.
To preserve this separation, a new version of QUIC SHOULD define new To preserve this separation, a new version of QUIC SHOULD define new
labels for key derivation for packet protection key and IV, plus the labels for key derivation for packet protection key and IV, plus the
packet number protection keys. header protection keys.
The initial secrets also use a key that is specific to the negotiated The initial secrets also use a key that is specific to the negotiated
QUIC version. New QUIC versions SHOULD define a new salt value used QUIC version. New QUIC versions SHOULD define a new salt value used
in calculating initial secrets. in calculating initial secrets.
10. IANA Considerations 10. IANA Considerations
This document does not create any new IANA registries, but it This document does not create any new IANA registries, but it
registers the values in the following registries: registers the values in the following registries:
skipping to change at page 32, line 33 skipping to change at page 32, line 37
[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-17 (work and Congestion Control", draft-ietf-quic-recovery-18 (work
in progress), December 2018. in progress), January 2019.
[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-17 (work in progress), December 2018. transport-18 (work in progress), January 2019.
[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 33, line 40 skipping to change at page 33, line 45
Transport Layer Security (TLS)", RFC 6655, Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012, DOI 10.17487/RFC6655, July 2012,
<https://www.rfc-editor.org/info/rfc6655>. <https://www.rfc-editor.org/info/rfc6655>.
[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-17 (work in progress), QUIC", draft-ietf-quic-http-18 (work in progress), January
December 2018. 2019.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
11.3. URIs 11.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. Change Log Appendix A. Sample Initial Packet Protection
This section shows examples of packet protection for Initial packets
so that implementations can be verified incrementally. These packets
use an 8-byte client-chosen Destination Connection ID of
0x8394c8f03e515708. Values for both server and client packet
protection are shown together with values in hexadecimal.
A.1. Keys
The labels generated by the HKDF-Expand-Label function are:
client in: 00200f746c73313320636c69656e7420696e00
server in: 00200f746c7331332073657276657220696e00
quic key: 00100e746c7331332071756963206b657900
quic iv: 000c0d746c733133207175696320697600
quic hp: 00100d746c733133207175696320687000
The initial secret is common:
initial_secret = HKDF-Extract(initial_salt, cid)
= 4496d3903d3f97cc5e45ac5790ddc686
683c7c0067012bb09d900cc21832d596
The secrets for protecting client packets are:
client_initial_secret
= HKDF-Expand-Label(initial_secret, "client in", _, 32)
= 8a3515a14ae3c31b9c2d6d5bc58538ca
5cd2baa119087143e60887428dcb52f6
key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
= 98b0d7e5e7a402c67c33f350fa65ea54
iv = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
= 19e94387805eb0b46c03a788
hp = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
= 0edd982a6ac527f2eddcbb7348dea5d7
The secrets for protecting server packets are:
server_initial_secret
= HKDF-Expand-Label(initial_secret, "server in", _, 32)
= 47b2eaea6c266e32c0697a9e2a898bdf
5c4fb3e5ac34f0e549bf2c58581a3811
key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
= 9a8be902a9bdd91d16064ca118045fb4
iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
= 0a82086d32205ba22241d8dc
hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
= 94b9452d2b3c7c7f6da7fdd8593537fd
A.2. Client Initial
The client sends an Initial packet. The unprotected payload of this
packet contains the following CRYPTO frame, plus enough PADDING
frames to make an 1163 byte payload:
060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1
4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
736572766572ff01000100000a001400 12001d00170018001901000101010201
03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
05030603020308040805080604010501 060102010402050206020202002d0002
0101001c00024001
The unprotected header includes the connection ID and a 4 byte packet
number encoding for a packet number of 2:
c3ff000012508394c8f03e51570800449f00000002
Protecting the payload produces output that is sampled for header
protection. Because the header uses a 4 byte packet number encoding,
the first 16 bytes of the protected payload is sampled, then applied
to the header:
sample = 0000f3a694c75775b4e546172ce9e047
mask = AES-ECB(hp, sample)[0..4]
= 020dbc1958
header[0] ^= mask[0] & 0x0f
= c1
header[17..20] ^= mask[1..4]
= 0dbc195a
header = c1ff000012508394c8f03e51570800449f0dbc195a
The resulting protected packet is:
c1ff000012508394c8f03e5157080044 9f0dbc195a0000f3a694c75775b4e546
172ce9e047cd0b5bee5181648c727adc 87f7eae54473ec6cba6bdad4f5982317
4b769f12358abd292d4f3286934484fb 8b239c38732e1f3bbbc6a003056487eb
8b5c88b9fd9279ffff3b0f4ecf95c462 4db6d65d4113329ee9b0bf8cdd7c8a8d
72806d55df25ecb66488bc119d7c9a29 abaf99bb33c56b08ad8c26995f838bb3
b7a3d5c1858b8ec06b839db2dcf918d5 ea9317f1acd6b663cc8925868e2f6a1b
da546695f3c3f33175944db4a11a346a fb07e78489e509b02add51b7b203eda5
c330b03641179a31fbba9b56ce00f3d5 b5e3d7d9c5429aebb9576f2f7eacbe27
bc1b8082aaf68fb69c921aa5d33ec0c8 510410865a178d86d7e54122d55ef2c2
bbc040be46d7fece73fe8a1b24495ec1 60df2da9b20a7ba2f26dfa2a44366dbc
63de5cd7d7c94c57172fe6d79c901f02 5c0010b02c89b395402c009f62dc053b
8067a1e0ed0a1e0cf5087d7f78cbd94a fe0c3dd55d2d4b1a5cfe2b68b86264e3
51d1dcd858783a240f893f008ceed743 d969b8f735a1677ead960b1fb1ecc5ac
83c273b49288d02d7286207e663c45e1 a7baf50640c91e762941cf380ce8d79f
3e86767fbbcd25b42ef70ec334835a3a 6d792e170a432ce0cb7bde9aaa1e7563
7c1c34ae5fef4338f53db8b13a4d2df5 94efbfa08784543815c9c0d487bddfa1
539bc252cf43ec3686e9802d651cfd2a 829a06a9f332a733a4a8aed80efe3478
093fbc69c8608146b3f16f1a5c4eac93 20da49f1afa5f538ddecbbe7888f4355
12d0dd74fd9b8c99e3145ba84410d8ca 9a36dd884109e76e5fb8222a52e1473d
a168519ce7a8a3c32e9149671b16724c 6c5c51bb5cd64fb591e567fb78b10f9f
6fee62c276f282a7df6bcf7c17747bc9 a81e6c9c3b032fdd0e1c3ac9eaa5077d
e3ded18b2ed4faf328f49875af2e36ad 5ce5f6cc99ef4b60e57b3b5b9c9fcbcd
4cfb3975e70ce4c2506bcd71fef0e535 92461504e3d42c885caab21b782e2629
4c6a9d61118cc40a26f378441ceb48f3 1a362bf8502a723a36c63502229a462c
c2a3796279a5e3a7f81a68c7f81312c3 81cc16a4ab03513a51ad5b54306ec1d7
8a5e47e2b15e5b7a1438e5b8b2882dbd ad13d6a4a8c3558cae043501b68eb3b0
40067152337c051c40b5af809aca2856 986fd1c86a4ade17d254b6262ac1bc07
7343b52bf89fa27d73e3c6f3118c9961 f0bebe68a5c323c2d84b8c29a2807df6
63635223242a2ce9828d4429ac270aab 5f1841e8e49cf433b1547989f419caa3
c758fff96ded40cf3427f0761b678daa 1a9e5554465d46b7a917493fc70f9ec5
e4e5d786ca501730898aaa1151dcd318 29641e29428d90e6065511c24d3109f7
cba32225d4accfc54fec42b733f95852 52ee36fa5ea0c656934385b468eee245
315146b8c047ed27c519b2c0a52d33ef e72c186ffe0a230f505676c5324baa6a
e006a73e13aa8c39ab173ad2b2778eea 0b34c46f2b3beae2c62a2c8db238bf58
fc7c27bdceb96c56d29deec87c12351b fd5962497418716a4b915d334ffb5b92
ca94ffe1e4f78967042638639a9de325 357f5f08f6435061e5a274703936c06f
c56af92c420797499ca431a7abaa4618 63bca656facfad564e6274d4a741033a
ca1e31bf63200df41cdf41c10b912bec
A.3. Server Initial
The server sends the following payload in response, including an ACK
frame, a CRYPTO frame, and no PADDING frames:
0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
0304
The header from the server includes a new connection ID and a 2-byte
packet number encoding for a packet number of 1:
c1ff00001205f067a5502a4262b50040740001
As a result, after protection, the header protection sample is taken
starting from the third protected octet:
sample = c4c2a2303d297e3c519bf6b22386e3d0
mask = 75f7ec8b62
header = c4ff00001205f067a5502a4262b5004074f7ed
The final protected packet is then:
c4ff00001205f067a5502a4262b50040 74f7ed5f01c4c2a2303d297e3c519bf6
b22386e3d0bd6dfc6612167729803104 1bb9a79c9f0f9d4c5877270a660f5da3
6207d98b73839b2fdf2ef8e7df5a51b1 7b8c68d864fd3e708c6c1b71a98a3318
15599ef5014ea38c44bdfd387c03b527 5c35e009b6238f831420047c7271281c
cb54df7884
Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
A.1. Since draft-ietf-quic-tls-14 B.1. Since draft-ietf-quic-tls-17
o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045)
o Use of ALPN or equivalent is mandatory (#2263, #2284)
B.2. Since draft-ietf-quic-tls-14
o Update the salt used for Initial secrets (#1970) o Update the salt used for Initial secrets (#1970)
o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
o Change header protection o Change header protection
* Sample from a fixed offset (#1575, #2030) * Sample from a fixed offset (#1575, #2030)
* Cover part of the first byte, including the key phase (#1322, * Cover part of the first byte, including the key phase (#1322,
skipping to change at page 34, line 34 skipping to change at page 39, line 4
o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
o Change header protection o Change header protection
* Sample from a fixed offset (#1575, #2030) * Sample from a fixed offset (#1575, #2030)
* Cover part of the first byte, including the key phase (#1322, * Cover part of the first byte, including the key phase (#1322,
#2006) #2006)
o TLS provides an AEAD and KDF function (#2046) o TLS provides an AEAD and KDF function (#2046)
* Clarify that the TLS KDF is used with TLS (#1997) * Clarify that the TLS KDF is used with TLS (#1997)
* Change the labels for calculation of QUIC keys (#1845, #1971, * Change the labels for calculation of QUIC keys (#1845, #1971,
#1991) #1991)
o Initial keys are discarded once Handshake are avaialble (#1951, o Initial keys are discarded once Handshake are avaialble (#1951,
#2045) #2045)
A.2. Since draft-ietf-quic-tls-13 B.3. Since draft-ietf-quic-tls-13
o Updated to TLS 1.3 final (#1660) o Updated to TLS 1.3 final (#1660)
A.3. Since draft-ietf-quic-tls-12 B.4. Since draft-ietf-quic-tls-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450) #1165, #1190, #1233, #1242, #1252, #1450)
* The cryptographic handshake uses CRYPTO frames, not stream 0 * The cryptographic handshake uses CRYPTO frames, not stream 0
* QUIC packet protection is used in place of TLS record * QUIC packet protection is used in place of TLS record
protection protection
* Separate QUIC packet number spaces are used for the handshake * Separate QUIC packet number spaces are used for the handshake
* Changed Retry to be independent of the cryptographic handshake * Changed Retry to be independent of the cryptographic handshake
* Limit the use of HelloRetryRequest to address TLS needs (like * Limit the use of HelloRetryRequest to address TLS needs (like
key shares) key shares)
o Changed codepoint of TLS extension (#1395, #1402) o Changed codepoint of TLS extension (#1395, #1402)
A.4. Since draft-ietf-quic-tls-11 B.5. Since draft-ietf-quic-tls-11
o Encrypted packet numbers. o Encrypted packet numbers.
A.5. Since draft-ietf-quic-tls-10 B.6. Since draft-ietf-quic-tls-10
o No significant changes. o No significant changes.
A.6. Since draft-ietf-quic-tls-09 B.7. 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)
A.7. Since draft-ietf-quic-tls-08 B.8. 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)
A.8. Since draft-ietf-quic-tls-07 B.9. 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)
A.9. Since draft-ietf-quic-tls-05 B.10. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
A.10. Since draft-ietf-quic-tls-04 B.11. 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)
A.11. Since draft-ietf-quic-tls-03 B.12. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
A.12. Since draft-ietf-quic-tls-02 B.13. Since draft-ietf-quic-tls-02
o Updates to match changes in transport draft o Updates to match changes in transport draft
A.13. Since draft-ietf-quic-tls-01 B.14. 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 36, line 32 skipping to change at page 41, line 4
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)
o Add interface necessary for client address validation (#275) o Add interface necessary for client address validation (#275)
o Define peer authentication (#140) o Define peer authentication (#140)
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)
A.14. Since draft-ietf-quic-tls-00 B.15. 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
A.15. Since draft-thomson-quic-tls-01 B.16. 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 Acknowledgments
This document has benefited from input from Dragana Damjanovic, This document has benefited from input from Dragana Damjanovic,
skipping to change at page 37, line 28 skipping to change at page 41, line 44
Contributors Contributors
Ryan Hamilton was originally an author of this specification. 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: mt@lowentropy.net
Sean Turner (editor) Sean Turner (editor)
sn3rd sn3rd
Email: sean@sn3rd.com Email: sean@sn3rd.com
 End of changes. 39 change blocks. 
71 lines changed or deleted 254 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/