RFC 9001: Using TLS to Secure QUIC | RFC Editor

This document describes how Transport Layer Security (TLS) is used to secure QUIC.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9001.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document describes how QUIC [QUIC-TRANSPORT] is secured using TLS [TLS13].¶
TLS 1.3 provides critical latency improvements for connection establishment over previous versions. Absent packet loss, most new connections can be established and secured within a single round trip; on subsequent connections between the same client and server, the client can often send application data immediately, that is, using a zero round-trip setup.¶
This document describes how TLS acts as a security component of QUIC.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terminology established in [QUIC-TRANSPORT].¶
For brevity, the acronym TLS is used to refer to TLS 1.3, though a newer version could be used; see Section 4.2.¶
TLS provides two endpoints with a way to establish a means of communication over an untrusted medium (for example, the Internet). TLS enables authentication of peers and provides confidentiality and integrity protection for messages that endpoints exchange.¶
Internally, TLS is a layered protocol, with the structure shown in Figure 1.¶
Each content-layer message (e.g., handshake, alerts, and application data) is carried as a series of typed TLS records by the record layer. Records are individually cryptographically protected and then transmitted over a reliable transport (typically TCP), which provides sequencing and guaranteed delivery.¶
The TLS authenticated key exchange occurs between two endpoints: client and server. The client initiates the exchange and the server responds. If the key exchange completes successfully, both client and server will agree on a secret. TLS supports both pre-shared key (PSK) and Diffie-Hellman over either finite fields or elliptic curves ((EC)DHE) key exchanges. PSK is the basis for Early Data (0-RTT); the latter provides forward secrecy (FS) when the (EC)DHE keys are destroyed. The two modes can also be combined to provide forward secrecy while using the PSK for authentication.¶
After completing the TLS handshake, the client will have learned and authenticated an identity for the server, and the server is optionally able to learn and authenticate an identity for the client. TLS supports X.509 [RFC5280] certificate-based authentication for both server and client. When PSK key exchange is used (as in resumption), knowledge of the PSK serves to authenticate the peer.¶
The TLS key exchange is resistant to tampering by attackers, and it produces shared secrets that cannot be controlled by either participating peer.¶
TLS provides two basic handshake modes of interest to QUIC:¶
A simplified TLS handshake with 0-RTT application data is shown in Figure 2.¶
Figure 2 omits the EndOfEarlyData message, which is not used in QUIC; see Section 8.3. Likewise, neither ChangeCipherSpec nor KeyUpdate messages are used by QUIC. ChangeCipherSpec is redundant in TLS 1.3; see Section 8.4. QUIC has its own key update mechanism; see Section 6.¶
Data is protected using a number of encryption levels:¶
Application data can only appear in the early data and application data levels. Handshake and alert messages may appear in any level.¶
The 0-RTT handshake can be used if the client and server have previously communicated. In the 1-RTT handshake, the client is unable to send protected application data until it has received all of the handshake messages sent by the server.¶
QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality and integrity protection of packets. For this it uses keys derived from a TLS handshake [TLS13], but instead of carrying TLS records over QUIC (as with TCP), TLS handshake and alert messages are carried directly over the QUIC transport, which takes over the responsibilities of the TLS record layer, as shown in Figure 3.¶
QUIC also relies on TLS for authentication and negotiation of parameters that are critical to security and performance.¶
Rather than a strict layering, these two protocols cooperate: QUIC uses the TLS handshake; TLS uses the reliability, ordered delivery, and record layer provided by QUIC.¶
At a high level, there are two main interactions between the TLS and QUIC components:¶
Figure 4 shows these interactions in more detail, with the QUIC packet protection being called out specially.¶
Unlike TLS over TCP, QUIC applications that want to send data do not send it using TLS Application Data records. Rather, they send it as QUIC STREAM frames or other frame types, which are then carried in QUIC packets.¶
QUIC carries TLS handshake dat