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/ |