draft-ietf-quic-tls-19.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: September 12, 2019 sn3rd Expires: October 23, 2019 sn3rd
March 11, 2019 April 21, 2019
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-19 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 September 12, 2019. This Internet-Draft will expire on October 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 3, line 6 skipping to change at page 3, line 6
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 24 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 24
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security of Initial Messages . . . . . . . . . . . . . . . . 27 7. Security of Initial Messages . . . . . . . . . . . . . . . . 27
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 28 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 28
8.1. Protocol and Version Negotiation . . . . . . . . . . . . 28 8.1. Protocol and Version Negotiation . . . . . . . . . . . . 28
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 28 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 28
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 29 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 29 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 30
9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 30 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 31
9.3. Peer Denial of Service . . . . . . . . . . . . . . . . . 31 9.3. Peer Denial of Service . . . . . . . . . . . . . . . . . 31
9.4. Header Protection Analysis . . . . . . . . . . . . . . . 31 9.4. Header Protection Analysis . . . . . . . . . . . . . . . 31
9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 32 9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 34
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Sample Initial Packet Protection . . . . . . . . . . 35 Appendix A. Sample Initial Packet Protection . . . . . . . . . . 35
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Note that it is not possible to send the following frames in 0-RTT Note that it is not possible to send the following frames in 0-RTT
for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
RETIRE_CONNECTION_ID. RETIRE_CONNECTION_ID.
Because packets could be reordered on the wire, QUIC uses the packet Because packets could be reordered on the wire, QUIC uses the packet
type to indicate which level a given packet was encrypted under, as type to indicate which level a given packet was encrypted under, as
shown in Table 1. When multiple packets of different encryption shown in Table 1. When multiple packets of different encryption
levels need to be sent, endpoints SHOULD use coalesced packets to levels need to be sent, endpoints SHOULD use coalesced packets to
send them in the same UDP datagram. send them in the same UDP datagram.
+-----------------+------------------+-----------+ +---------------------+------------------+-----------+
| Packet Type | Encryption Level | PN Space | | Packet Type | Encryption Level | PN Space |
+-----------------+------------------+-----------+ +---------------------+------------------+-----------+
| Initial | Initial secrets | Initial | | Initial | Initial secrets | Initial |
| | | | | | | |
| 0-RTT Protected | 0-RTT | 0/1-RTT | | 0-RTT Protected | 0-RTT | 0/1-RTT |
| | | | | | | |
| Handshake | Handshake | Handshake | | Handshake | Handshake | Handshake |
| | | | | | | |
| Retry | N/A | N/A | | Retry | N/A | N/A |
| | | | | | | |
| Short Header | 1-RTT | 0/1-RTT | | Version Negotiation | N/A | N/A |
+-----------------+------------------+-----------+ | | | |
| Short Header | 1-RTT | 0/1-RTT |
+---------------------+------------------+-----------+
Table 1: Encryption Levels by Packet Type Table 1: Encryption Levels by Packet Type
Section 17 of [QUIC-TRANSPORT] shows how packets at the various Section 17 of [QUIC-TRANSPORT] shows how packets at the various
encryption levels fit into the handshake process. encryption levels fit into the handshake process.
4.1. Interface to TLS 4.1. Interface to TLS
As shown in Figure 2, the interface from QUIC to TLS consists of As shown in Figure 2, the interface from QUIC to TLS consists of
three primary functions: three primary functions:
skipping to change at page 11, line 17 skipping to change at page 11, line 17
When the handshake is complete, QUIC only needs to provide TLS with When the handshake is complete, QUIC only needs to provide TLS with
any data that arrives in CRYPTO streams. In the same way that is any data that arrives in CRYPTO streams. In the same way that is
done during the handshake, new data is requested from TLS after done during the handshake, new data is requested from TLS after
providing received data. providing received data.
Important: Until the handshake is reported as complete, the Important: Until the handshake is reported as complete, the
connection and key exchange are not properly authenticated at the connection and key exchange are not properly authenticated at the
server. Even though 1-RTT keys are available to a server after server. Even though 1-RTT keys are available to a server after
receiving the first handshake messages from a client, the server receiving the first handshake messages from a client, the server
cannot consider the client to be authenticated until it receives cannot consider the client to be authenticated until it receives
and validates the client's Finished message. and validates the client's Finished message. A server MUST NOT
process 1-RTT packets until the handshake is complete. A server
MAY buffer or discard 1-RTT packets that it cannot read.
The requirement for the server to wait for the client Finished The requirement for the server to wait for the client Finished
message creates a dependency on that message being delivered. A message creates a dependency on that message being delivered. A
client can avoid the potential for head-of-line blocking that this client can avoid the potential for head-of-line blocking that this
implies by sending a copy of the CRYPTO frame that carries the implies by sending a copy of the CRYPTO frame that carries the
Finished message in multiple packets. This enables immediate Finished message in multiple packets. This enables immediate
server processing for those packets. server processing for those packets.
4.1.2. Encryption Level Changes 4.1.2. Encryption Level Changes
skipping to change at page 13, line 9 skipping to change at page 13, line 9
4.1.3. TLS Interface Summary 4.1.3. TLS Interface Summary
Figure 3 summarizes the exchange between QUIC and TLS for both client Figure 3 summarizes the exchange between QUIC and TLS for both client
and server. Each arrow is tagged with the encryption level used for and server. Each arrow is tagged with the encryption level used for
that transmission. that transmission.
Client Server Client Server
Get Handshake Get Handshake
Initial -------------> Initial ------------->
Rekey tx to 0-RTT Keys Install tx 0-RTT Keys
0-RTT ---------------> 0-RTT --------------->
Handshake Received Handshake Received
Get Handshake Get Handshake
<------------- Initial <------------- Initial
Rekey rx to 0-RTT keys Install rx 0-RTT keys
Handshake Received Install Handshake keys
Rekey rx to Handshake keys
Get Handshake Get Handshake
<----------- Handshake <----------- Handshake
Rekey tx to 1-RTT keys Install tx 1-RTT keys
<--------------- 1-RTT <--------------- 1-RTT
Handshake Received Handshake Received
Rekey rx to Handshake keys Install tx Handshake keys
Handshake Received Handshake Received
Get Handshake Get Handshake
Handshake Complete Handshake Complete
Handshake -----------> Handshake ----------->
Rekey tx to 1-RTT keys Install 1-RTT keys
1-RTT ---------------> 1-RTT --------------->
Handshake Received Handshake Received
Rekey rx to 1-RTT keys Install rx 1-RTT keys
Get Handshake
Handshake Complete Handshake Complete
Get Handshake
<--------------- 1-RTT <--------------- 1-RTT
Handshake Received Handshake Received
Figure 3: Interaction Summary between QUIC and TLS Figure 3: Interaction Summary between QUIC and TLS
4.2. TLS Version 4.2. TLS Version
This document describes how TLS 1.3 [TLS13] is used with QUIC. This document describes how TLS 1.3 [TLS13] is used with QUIC.
In practice, the TLS handshake will negotiate a version of TLS to In practice, the TLS handshake will negotiate a version of TLS to
skipping to change at page 28, line 31 skipping to change at page 28, line 31
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.
QUIC requires that the cryptographic handshake provide authenticated QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation. TLS uses Application Layer Protocol protocol negotiation. TLS uses Application Layer Protocol
Negotiation (ALPN) [RFC7301] to select an application protocol. Negotiation (ALPN) [RFC7301] to select an application protocol.
Unless another mechanism is used for agreeing on an application Unless another mechanism is used for agreeing on an application
protocol, endpoints MUST use ALPN for this purpose. When using ALPN, protocol, endpoints MUST use ALPN for this purpose. When using ALPN,
endpoints MUST abort a connection if an application protocol is not endpoints MUST immediately close a connection (see Section 10.3 in
negotiated. [QUIC-TRANSPORT]) if an application protocol is not negotiated with a
no_application_protocol TLS alert (QUIC error code 0x178, see
Section 4.8). While [RFC7301] only specifies that servers use this
alert, QUIC clients MUST also use it to terminate a connection when
ALPN negotiation fails.
An application-layer protocol MAY restrict the QUIC versions that it An application-layer protocol MAY restrict the QUIC versions that it
can operate over. Servers MUST select an application protocol can operate over. Servers MUST select an application protocol
compatible with the QUIC version that the client has selected. If compatible with the QUIC version that the client has selected. If
the server cannot select a compatible combination of application 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
skipping to change at page 29, line 22 skipping to change at page 29, line 26
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.
Endpoints MUST NOT send this extension in a TLS connection that does Endpoints MUST NOT send this extension in a TLS connection that does
not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A
fatal unsupported_extension alert MUST be sent if this extension is fatal unsupported_extension alert MUST be sent by an implementation
received when the transport is not QUIC. that supports this extension if the extension is received when the
transport is not QUIC.
8.3. Removing the EndOfEarlyData Message 8.3. Removing the EndOfEarlyData Message
The TLS EndOfEarlyData message is not used with QUIC. QUIC does not The TLS EndOfEarlyData message is not used with QUIC. QUIC does not
rely on this message to mark the end of 0-RTT data or to signal the rely on this message to mark the end of 0-RTT data or to signal the
change to Handshake keys. change to Handshake keys.
Clients MUST NOT send the EndOfEarlyData message. A server MUST Clients MUST NOT send the EndOfEarlyData message. A server MUST
treat receipt of a CRYPTO frame in a 0-RTT packet as a connection treat receipt of a CRYPTO frame in a 0-RTT packet as a connection
error of type PROTOCOL_VIOLATION. error of type PROTOCOL_VIOLATION.
skipping to change at page 33, line 37 skipping to change at page 33, line 43
[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-19 (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-19 (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 34, line 45 skipping to change at page 34, line 50
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-19 (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. 18 change blocks. 
37 lines changed or deleted 45 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/