RFC 9001

Using TLS to Secure QUIC
Standards Track
May 2021
RFC Library > TLS & DTLS > RFC 9001
Abstract: This document describes how TLS 1.3 is used to secure QUIC. QUIC uses the TLS handshake for key negotiation and authentication, but replaces the TLS record layer with QUIC's own transport. The integration provides 0-RTT data, header protection, and separate encryption levels for each handshake phase.
Canonical source: https://www.rfc-editor.org/rfc/rfc9001  |  IETF Datatracker

Overview

▶

RFC 9001 specifies the integration between TLS 1.3 and QUIC. Unlike traditional TLS-over-TCP, QUIC does not use the TLS record layer for encryption. Instead, TLS provides the handshake protocol and key schedule, while QUIC handles packet protection directly.

This split design allows QUIC to encrypt packets at different protection levels during the handshake and provides header protection that TLS-over-TCP cannot offer.

Encryption Levels

▶

Each encryption level uses distinct keys derived from the TLS key schedule via HKDF. Packet number encryption (header protection) uses a separate key derived from the same traffic secret.

Level QUIC Packet Type Keys From Protects
Initial Initial packets Connection ID-derived First flight (unverified peer)
Handshake Handshake packets Handshake traffic secret Certificate exchange
0-RTT 0-RTT packets Pre-shared key (resumption) Early application data
1-RTT Short header packets Application traffic secret All post-handshake data

TLS-QUIC Interface

▶

TLS handshake messages are carried in QUIC CRYPTO frames, not TLS records. QUIC provides the reliable, ordered delivery that TLS expects (per encryption level). Once keys are derived, QUIC uses them directly for AEAD encryption of packets.

  ┌────────────────────────────────┐
│     TLS 1.3 Handshake         │
│  (ClientHello, ServerHello,   │
│   Certificates, Finished)     │
└──────────┬───────────────┬────┘
│ CRYPTO frames │ Key schedule
▼               ▼
┌────────────────────────────────┐
│         QUIC Transport        │
│  - Packet protection (AEAD)   │
│  - Header protection          │
│  - Packet number encryption   │
│  - Key update mechanism       │
└────────────────────────────────┘

Key Derivation

▶

QUIC uses the TLS 1.3 key schedule (HKDF-based) to derive packet protection keys. For each encryption level, the traffic secret is expanded into a key, IV, and header protection key.

  • quic key: HKDF-Expand-Label(secret, "quic key", "", key_length) — AEAD encryption key
  • quic iv: HKDF-Expand-Label(secret, "quic iv", "", 12) — AEAD nonce/IV
  • quic hp: HKDF-Expand-Label(secret, "quic hp", "", key_length) — header protection key

Header Protection

▶

QUIC encrypts the packet number and certain header flags using a header protection algorithm. This prevents on-path observers from reading packet numbers, which could be used for traffic analysis. The header protection key is derived from the same traffic secret used for packet protection.

Privacy benefit: Header protection makes it difficult for middleboxes to correlate QUIC packets or perform traffic analysis based on packet numbers. This is a significant privacy improvement over TCP+TLS.

Key Update

▶

QUIC supports key updates without a full TLS handshake. Either endpoint can initiate a key update by toggling the Key Phase bit in the short header. The new keys are derived from the current application traffic secret using HKDF-Expand-Label.

3GPP Relevance

▶
  • QUIC/HTTP/3 security: Defines the security model for any future HTTP/3-based SBI transport
  • TLS 1.3 reuse: Uses the same TLS 1.3 cipher suites mandated by TS 29.500 for SBI security
  • 0-RTT considerations: Replay protection for 0-RTT data is critical in NF-to-NF communication
  • Key update: Long-lived NF connections benefit from periodic key rotation without connection restart
  • Middlebox challenges: Header protection prevents inspection by intermediate network functions