ML-KEM Post-Quantum Key Agreement for TLS 1.3#

Deirdre Connolly (Selkie Cryptography, TLS WG)

• Why: The standalone post-quantum key agreement for TLS 1.3 is essentially done — this defines what PQ TLS looks like at the wire level for every product the PM ships.
• What: Registers ML-KEM-512/768/1024 as TLS NamedGroups (0x0200–0x0202) for use in supported_groups/key_share, replacing (EC)DHE in the TLS 1.3 key schedule. Encapsulation keys run 800–1568 bytes with 768–1568-byte ciphertexts — the handshake-size implications every implementation will feel.
• How: Client sends pk in KeyShareClientHello; server returns the ML-KEM ciphertext in KeyShareServerHello; the 32-byte shared secret feeds the key schedule. Server must run the FIPS 203 encapsulation-key check (abort illegal_parameter on failure); ciphertext reuse is forbidden; RNG hygiene is called out (encapsulation randomness discloses raw RNG output). Security considerations cite formal analyses that IND-CCA-secure KEM substitution preserves TLS 1.3 handshake security, and hybrid constructions (RFC 9954, RFC 10024) give compositional safety. Intended status is Informational; the registry entries are currently Recommended=N.
• Where applicable: All TLS 1.3/DTLS 1.3 implementations. Maturity: WG draft at -11, submitted to IESG, in the RFC Editor queue with completed SECDIR/GenArt last-call reviews. Decisions remaining for implementers are deployment-level — standalone ML-KEM vs. PQ/T hybrids — not the spec itself.