Skip to content

IETF and hybrid TLS 1.3 key exchange

NIST defines the algorithms; the IETF defines how they travel over the wire. The headline output is hybrid key exchange for TLS 1.3 — combining X25519 with ML-KEM so recorded handshakes stay safe.

IT & securityDeep dive5 min· Updated Jul 22, 2026

A new algorithm is useless until protocols know how to carry it. That is the Internet Engineering Task Force's (IETF) job: it defines the on-the-wire formats and negotiation for TLS, IKEv2/IPsec, SSH, X.509 certificates, and CMS. For post-quantum, the most consequential work is putting ML-KEM into the TLS 1.3 handshake.

Hybrid key exchange

Rather than switch TLS straight to a brand-new algorithm, the IETF's hybrid design runs a classical key exchange and a post-quantum one together and combines both shared secrets, so the connection is secure as long as either component holds. The widely deployed named group is X25519MLKEM768 — X25519 for classical security and continuity, ML-KEM-768 for post-quantum protection. Major browsers and servers already support it, which is why hybrid is the practical first step against harvest-now-decrypt-later.

Decision

Why hybrid rather than pure PQC

Hybrid hedges two risks at once: a possible undiscovered flaw in the new post-quantum algorithm (the classical half still protects you), and harvest-now-decrypt-later (the post-quantum half protects recorded traffic). It also stays interoperable with clients that only understand the classical group. Pure-PQC comes later, once confidence and support are universal.

Beyond TLS

  • **IPsec/IKEv2** — RFCs define post-quantum and hybrid key exchange for VPNs, including a mechanism to inject additional (PQC) key exchanges into IKEv2.
  • **X.509 and CMS** — the LAMPS working group is standardizing how ML-DSA, SLH-DSA, and composite/hybrid signatures appear in certificates and signed messages.
  • **SSH** — post-quantum hybrid key exchange methods are being specified and shipped in common implementations.

The division of labour is worth remembering for compliance: cite NIST FIPS for the algorithm, and cite the relevant IETF RFC or draft for how it is used in a specific protocol. An auditor asking "is your TLS quantum-safe" is really asking which named group you negotiate, which is an IETF artifact.