draft-ietf-quic-tls-18.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: July 27, 2019 sn3rd Expires: August 23, 2019 sn3rd
January 23, 2019 February 19, 2019
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-18 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 July 27, 2019. This Internet-Draft will expire on August 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 5 skipping to change at page 6, line 5
() Indicates messages protected by early data (0-RTT) keys () Indicates messages protected by early data (0-RTT) keys
{} Indicates messages protected using handshake keys {} Indicates messages protected using handshake keys
[] Indicates messages protected using application data [] Indicates messages protected using application data
(1-RTT) keys (1-RTT) keys
Figure 1: TLS Handshake with 0-RTT Figure 1: TLS Handshake with 0-RTT
Data is protected using a number of encryption levels: Data is protected using a number of encryption levels:
o Plaintext o Initial Keys
o Early Data (0-RTT) Keys o Early Data (0-RTT) Keys
o Handshake Keys o Handshake Keys
o Application Data (1-RTT) Keys o Application Data (1-RTT) Keys
Application data may appear only in the early data and application Application data may appear only in the early data and application
data levels. Handshake and Alert messages may appear in any level. data levels. Handshake and Alert messages may appear in any level.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality
and integrity protection of packets. For this it uses keys derived and integrity protection of packets. For this it uses keys derived
from a TLS handshake [TLS13], but instead of carrying TLS records from a TLS handshake [TLS13], but instead of carrying TLS records
over QUIC (as with TCP), TLS Handshake and Alert messages are carried over QUIC (as with TCP), TLS Handshake and Alert messages are carried
directly over the QUIC transport, which takes over the directly over the QUIC transport, which takes over the
responsibilities of the TLS record layer, as shown below. responsibilities of the TLS record layer, as shown below.
+--------------+--------------+ +-------------+ +--------------+--------------+ +-------------+
| TLS | TLS | | QUIC | | TLS | TLS | | QUIC |
| Handshake | Alerts | | Applications| | Handshake | Alerts | | Applications|
| | | | (h2q, etc.) | | | | | (h3, etc.) |
+--------------+--------------+-+-------------+ +--------------+--------------+-+-------------+
| | | |
| QUIC Transport | | QUIC Transport |
| (streams, reliability, congestion, etc.) | | (streams, reliability, congestion, etc.) |
| | | |
+---------------------------------------------+ +---------------------------------------------+
| | | |
| QUIC Packet Protection | | QUIC Packet Protection |
| | | |
+---------------------------------------------+ +---------------------------------------------+
skipping to change at page 18, line 24 skipping to change at page 18, line 24
Each encryption level has separate secret values for protection of Each encryption level has separate secret values for protection of
packets sent in each direction. These traffic secrets are derived by packets sent in each direction. These traffic secrets are derived by
TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all
encryption levels except the Initial encryption level. The secrets encryption levels except the Initial encryption level. The secrets
for the Initial encryption level are computed based on the client's for the Initial encryption level are computed based on the client's
initial Destination Connection ID, as described in Section 5.2. initial Destination Connection ID, as described in Section 5.2.
The keys used for packet protection are computed from the TLS secrets The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of [TLS13]) is used, using the hash function described in Section 7.1 of [TLS13] is used, using the hash
function from the negotiated cipher suite. Other versions of TLS function from the negotiated cipher suite. Other versions of TLS
MUST provide a similar function in order to be used QUIC. MUST provide a similar function in order to be used with QUIC.
The current encryption level secret and the label "quic key" are The current encryption level secret and the label "quic key" are
input to the KDF to produce the AEAD key; the label "quic iv" is used input to the KDF to produce the AEAD key; the label "quic iv" is used
to derive the IV, see Section 5.3. The header protection key uses to derive the IV, see Section 5.3. The header protection key uses
the "quic hp" label, see Section 5.4). Using these labels provides the "quic hp" label, see Section 5.4. Using these labels provides
key separation between QUIC and TLS, see Section 9.4. key separation between QUIC and TLS, see Section 9.4.
The KDF used for initial secrets is always the HKDF-Expand-Label The KDF used for initial secrets is always the HKDF-Expand-Label
function from TLS 1.3 (see Section 5.2). function from TLS 1.3 (see Section 5.2).
5.2. Initial Secrets 5.2. Initial Secrets
Initial packets are protected with a secret derived from the Initial packets are protected with a secret derived from the
Destination Connection ID field from the client's first Initial Destination Connection ID field from the client's first Initial
packet of the connection. Specifically: packet of the connection. Specifically:
skipping to change at page 19, line 18 skipping to change at page 19, line 18
The connection ID used with HKDF-Expand-Label is the Destination The connection ID used with HKDF-Expand-Label is the Destination
Connection ID in the Initial packet sent by the client. This will be Connection ID in the Initial packet sent by the client. This will be
a randomly-selected value unless the client creates the Initial a randomly-selected value unless the client creates the Initial
packet after receiving a Retry packet, where the Destination packet after receiving a Retry packet, where the Destination
Connection ID is selected by the server. Connection ID is selected by the server.
The value of initial_salt is a 20 byte sequence shown in the figure The value of initial_salt is a 20 byte sequence shown in the figure
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 packets from
packets from future versions. 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. 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
skipping to change at page 19, line 50 skipping to change at page 19, line 50
used. used.
Packets are protected prior to applying header protection Packets are protected prior to applying header protection
(Section 5.4). The unprotected packet header is part of the (Section 5.4). The unprotected packet header 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 header protection. first removes the header protection.
All QUIC packets other than Version Negotiation and Retry packets are All QUIC packets other than Version Negotiation and Retry packets are
protected with an AEAD algorithm [AEAD]. Prior to establishing a protected with an AEAD algorithm [AEAD]. Prior to establishing a
shared secret, packets are protected with AEAD_AES_128_GCM and a key shared secret, packets are protected with AEAD_AES_128_GCM and a key
derived from the destination connection ID in the client's first derived from the Destination Connection ID in the client's first
Initial packet (see Section 5.2). This provides protection against Initial packet (see Section 5.2). This provides protection against
off-path attackers and robustness against QUIC version unaware off-path attackers and robustness against QUIC version unaware
middleboxes, but not against on-path attackers. middleboxes, but not against on-path attackers.
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
skipping to change at page 29, line 8 skipping to change at page 29, line 8
Including transport parameters in the TLS handshake provides Including transport parameters in the TLS handshake provides
integrity protection for these values. integrity protection for these values.
enum { enum {
quic_transport_parameters(0xffa5), (65535) quic_transport_parameters(0xffa5), (65535)
} ExtensionType; } ExtensionType;
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in contains a value that is defined by the version of QUIC that is in
use. The quic_transport_parameters extension carries a use. The quic_transport_parameters extension carries a
TransportParameters when the version of QUIC defined in TransportParameters struct when the version of QUIC defined in
[QUIC-TRANSPORT] is used. [QUIC-TRANSPORT] is used.
The quic_transport_parameters extension is carried in the ClientHello The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake. and the EncryptedExtensions messages during the handshake.
While the transport parameters are technically available prior to the While the transport parameters are technically available prior to the
completion of the handshake, they cannot be fully trusted until the completion of the handshake, they cannot be fully trusted until the
handshake completes, and reliance on them should be minimized. handshake completes, and reliance on them should be minimized.
However, any tampering with the parameters will cause the handshake However, any tampering with the parameters will cause the handshake
to fail. to fail.
skipping to change at page 31, line 38 skipping to change at page 31, line 38
For the sending of packets, construction and protection of packet For the sending of packets, construction and protection of packet
payloads and packet numbers MUST be free from side-channels that payloads and packet numbers MUST be free from side-channels that
would reveal the packet number or its encoded size. would reveal the packet number or its encoded size.
9.4. Key Diversity 9.4. Key Diversity
In using TLS, the central key schedule of TLS is used. As a result In using TLS, the central key schedule of TLS is used. As a result
of the TLS handshake messages being integrated into the calculation of the TLS handshake messages being integrated into the calculation
of secrets, the inclusion of the QUIC transport parameters extension of secrets, the inclusion of the QUIC transport parameters extension
ensures that handshake and 1-RTT keys are not the same as those that ensures that handshake and 1-RTT keys are not the same as those that
might be produced by a server running TLS over TCP. However, 0-RTT might be produced by a server running TLS over TCP. To avoid the
keys only include the ClientHello message and might therefore use the possibility of cross-protocol key synchronization, additional
same secrets. To avoid the possibility of cross-protocol key measures are provided to improve key separation.
synchronization, additional measures are provided to improve key
separation.
The QUIC packet protection keys and IVs are derived using a different The QUIC packet protection keys and IVs are derived using a different
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
header protection keys. header protection keys. This version of QUIC uses the string "quic".
Other versions can use a version-specific label in place of that
string.
The initial secrets also use a key that is specific to the negotiated The initial secrets use a key that is specific to the negotiated QUIC
QUIC version. New QUIC versions SHOULD define a new salt value used version. New QUIC versions SHOULD define a new salt value used in
in calculating initial secrets. 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:
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 8.2. The the quic_transport_parameters extension found in Section 8.2. 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.
skipping to change at page 32, line 37 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-18 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-18 (work in progress). transport-latest (work in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
skipping to change at page 33, line 45 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-18 (work in progress). QUIC", draft-ietf-quic-http-latest (work in progress).
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
 End of changes. 17 change blocks. 
26 lines changed or deleted 26 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/