draft-ietf-quic-tls-27.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: August 24, 2020 sn3rd Expires: September 30, 2020 sn3rd
February 21, 2020 March 29, 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-27 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 August 24, 2020. This Internet-Draft will expire on September 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 8, line 43 skipping to change at page 8, line 43
offset and length. Those frames are packaged into QUIC packets and offset and length. Those frames are packaged into QUIC packets and
encrypted under the current TLS encryption level. As with TLS over encrypted under the current TLS encryption level. As with TLS over
TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's
responsibility to deliver it reliably. Each chunk of data that is responsibility to deliver it reliably. Each chunk of data that is
produced by TLS is associated with the set of keys that TLS is produced by TLS is associated with the set of keys that TLS is
currently using. If QUIC needs to retransmit that data, it MUST use currently using. If QUIC needs to retransmit that data, it MUST use
the same keys even if TLS has already updated to newer keys. the same keys even if TLS has already updated to newer keys.
One important difference between TLS records (used with TCP) and QUIC One important difference between TLS records (used with TCP) and QUIC
CRYPTO frames is that in QUIC multiple frames may appear in the same CRYPTO frames is that in QUIC multiple frames may appear in the same
QUIC packet as long as they are associated with the same encryption QUIC packet as long as they are associated with the same packet
level. For instance, an implementation might bundle a Handshake number space. For instance, an endpoint can bundle a Handshake
message and an ACK for some Handshake data into the same packet. message and an ACK for some Handshake data into the same packet.
Some frames are prohibited in different encryption levels, others Some frames are prohibited in different packet number spaces. The
cannot be sent. The rules here generalize those of TLS, in that rules here generalize those of TLS, in that frames associated with
frames associated with establishing the connection can usually appear establishing the connection can usually appear in packets in any
at any encryption level, whereas those associated with transferring packet number space, whereas those associated with transferring data
data can only appear in the 0-RTT and 1-RTT encryption levels: can only appear in the application data packet number space:
o PADDING and PING frames MAY appear in packets of any encryption
level.
o CRYPTO frames and CONNECTION_CLOSE frames signaling errors at the o PADDING, PING, and CRYPTO frames MAY appear in any packet number
QUIC layer (type 0x1c) MAY appear in packets of any encryption space.
level except 0-RTT.
o CONNECTION_CLOSE frames signaling application errors (type 0x1d) o CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
MUST only be sent in packets at the 1-RTT encryption level. 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE
frames signaling application errors (type 0x1d) MUST only appear
in the application data packet number space.
o ACK frames MAY appear in packets of any encryption level other o ACK frames MAY appear in any packet number space, but can only
than 0-RTT, but can only acknowledge packets which appeared in acknowledge packets which appeared in that packet number space.
that packet number space. However, as noted below, 0-RTT packets cannot contain ACK frames.
o All other frame types MUST only be sent in the 0-RTT and 1-RTT o All other frame types MUST only be sent in the application data
levels. packet number space.
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, HANDSHAKE_DONE, NEW_TOKEN, packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
PATH_RESPONSE, and RETIRE_CONNECTION_ID. PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
of these frames in 0-RTT packets as a connection error of type
PROTOCOL_VIOLATION.
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 keys were used to protect a given packet, as
shown in Table 1. When multiple packets of different encryption shown in Table 1. When packets of different types need to be sent,
levels need to be sent, endpoints SHOULD use coalesced packets to endpoints SHOULD use coalesced packets to send them in the same UDP
send them in the same UDP datagram. datagram.
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
| Packet Type | Encryption Level | PN Space | | Packet Type | Encryption Keys | PN Space |
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
| Initial | Initial secrets | Initial | | Initial | Initial secrets | Initial |
| | | | | | | |
| 0-RTT Protected | 0-RTT | 0/1-RTT | | 0-RTT Protected | 0-RTT | Application data |
| | | | | | | |
| Handshake | Handshake | Handshake | | Handshake | Handshake | Handshake |
| | | | | | | |
| Retry | N/A | N/A | | Retry | Retry | N/A |
| | | | | | | |
| Version Negotiation | N/A | N/A | | Version Negotiation | N/A | N/A |
| | | | | | | |
| Short Header | 1-RTT | 0/1-RTT | | Short Header | 1-RTT | Application data |
+---------------------+------------------+-----------+ +---------------------+-----------------+------------------+
Table 1: Encryption Levels by Packet Type Table 1: Encryption Keys 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 4, the interface from QUIC to TLS consists of four As shown in Figure 4, the interface from QUIC to TLS consists of four
primary functions: primary functions:
o Sending and receiving handshake messages o Sending and receiving handshake messages
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Before starting the handshake QUIC provides TLS with the transport Before starting the handshake QUIC provides TLS with the transport
parameters (see Section 8.2) that it wishes to carry. parameters (see Section 8.2) that it wishes to carry.
A QUIC client starts TLS by requesting TLS handshake bytes from TLS. A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
The client acquires handshake bytes before sending its first packet. The client acquires handshake bytes before sending its first packet.
A QUIC server starts the process by providing TLS with the client's A QUIC server starts the process by providing TLS with the client's
handshake bytes. handshake bytes.
At any time, the TLS stack at an endpoint will have a current sending At any time, the TLS stack at an endpoint will have a current sending
encryption level and receiving encryption level. Each encryption encryption level and receiving encryption level. Encryption levels
level is associated with a different flow of bytes, which is reliably determine the packet type and keys that are used for protecting data.
transmitted to the peer in CRYPTO frames. When TLS provides
handshake bytes to be sent, they are appended to the current flow and Each encryption level is associated with a different sequence of
any packet that includes the CRYPTO frame is protected using keys bytes, which is reliably transmitted to the peer in CRYPTO frames.
from the corresponding encryption level. When TLS provides handshake bytes to be sent, they are appended to
the current flow. Any packet that includes the CRYPTO frame is
protected using keys from the corresponding encryption level. Four
encryption levels are used, producing keys for Initial, 0-RTT,
Handshake, and 1-RTT packets. CRYPTO frames are carried in just
three of these levels, omitting the 0-RTT level. These four levels
correspond to three packet number spaces: Initial and Handshake
encrypted packets use their own separate spaces; 0-RTT and 1-RTT
packets use the application data packet number space.
QUIC takes the unprotected content of TLS handshake records as the QUIC takes the unprotected content of TLS handshake records as the
content of CRYPTO frames. TLS record protection is not used by QUIC. content of CRYPTO frames. TLS record protection is not used by QUIC.
QUIC assembles CRYPTO frames into QUIC packets, which are protected QUIC assembles CRYPTO frames into QUIC packets, which are protected
using QUIC packet protection. using QUIC packet protection.
QUIC is only capable of conveying TLS handshake records in CRYPTO QUIC is only capable of conveying TLS handshake records in CRYPTO
frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error
codes; see Section 4.9. TLS application data and other message types codes; see Section 4.9. TLS application data and other message types
cannot be carried by QUIC at any encryption level and is an error if cannot be carried by QUIC at any encryption level and is an error if
skipping to change at page 17, line 46 skipping to change at page 17, line 46
the client is interpreted. Other applications using QUIC could have the client is interpreted. Other applications using QUIC could have
different requirements for determining whether to accept or reject different requirements for determining whether to accept or reject
early data. early data.
4.8. HelloRetryRequest 4.8. HelloRetryRequest
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
[TLS13]) can be used to correct a client's incorrect KeyShare [TLS13]) can be used to correct a client's incorrect KeyShare
extension as well as for a stateless round-trip check. From the extension as well as for a stateless round-trip check. From the
perspective of QUIC, this just looks like additional messages carried perspective of QUIC, this just looks like additional messages carried
in the Initial encryption level. Although it is in principle in Initial packets. Although it is in principle possible to use this
possible to use this feature for address verification in QUIC, QUIC feature for address verification in QUIC, QUIC implementations SHOULD
implementations SHOULD instead use the Retry feature (see Section 8.1 instead use the Retry feature (see Section 8.1 of [QUIC-TRANSPORT]).
of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key HelloRetryRequest is still used to request key shares.
shares.
4.9. TLS Errors 4.9. TLS Errors
If TLS experiences an error, it generates an appropriate alert as If TLS experiences an error, it generates an appropriate alert as
defined in Section 6 of [TLS13]. defined in Section 6 of [TLS13].
A TLS alert is turned into a QUIC connection error by converting the A TLS alert is turned into a QUIC connection error by converting the
one-byte alert description into a QUIC error code. The alert one-byte alert description into a QUIC error code. The alert
description is added to 0x100 to produce a QUIC error code from the description is added to 0x100 to produce a QUIC error code from the
range reserved for CRYPTO_ERROR. The resulting value is sent in a range reserved for CRYPTO_ERROR. The resulting value is sent in a
QUIC CONNECTION_CLOSE frame. QUIC CONNECTION_CLOSE frame of type 0x1c.
The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
generate alerts at the "warning" level. generate alerts at the "warning" level.
4.10. Discarding Unused Keys 4.10. Discarding Unused Keys
After QUIC moves to a new encryption level, packet protection keys After QUIC moves to a new encryption level, packet protection keys
for previous encryption levels can be discarded. This occurs several for previous encryption levels can be discarded. This occurs several
times during the handshake, as well as when keys are updated; see times during the handshake, as well as when keys are updated; see
Section 6. Section 6.
skipping to change at page 42, line 11 skipping to change at page 42, line 11
"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>.
[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-27 (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-27 (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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 42, line 49 skipping to change at page 42, line 49
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
[AEBounds] [AEBounds]
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", March 2016, Encryption Use in TLS", March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[HTTP2-TLS13] [HTTP2-TLS13]
Benjamin, D., "Using TLS 1.3 with HTTP/2", draft-ietf- Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
httpbis-http2-tls13-03 (work in progress), October 2019. DOI 10.17487/RFC8740, February 2020,
<https://www.rfc-editor.org/info/rfc8740>.
[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.
[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp. AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
235-265, DOI 10.1007/978-3-030-26948-7_9, 2019. 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-27 (work in progress). (HTTP/3)", 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. 20 change blocks. 
64 lines changed or deleted 72 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/