Essay TLS 1.3 ML-KEM

Hybrid PQC in TLS: what X25519MLKEM768 actually does

Chrome quietly turned post-quantum key exchange on by default for most users in 2024–2025. The handshake on the wire grew by about two kilobytes and the world barely noticed. Here is what's inside that handshake — and what your edge stack has to be able to do.

A TLS 1.3 handshake diagram showing the hybrid key exchange. The client sends a ClientHello carrying both an X25519 share and an ML-KEM-768 encapsulation key. The server responds with a ServerHello containing an X25519 share and an ML-KEM-768 ciphertext. Both shared secrets are concatenated and fed to HKDF-Extract; either holding secures the channel.
The X25519MLKEM768 hybrid TLS 1.3 key exchange in one frame.

The IANA codepoint 0x11EC is, mathematically, the most important number in any TLS handshake that uses it. It identifies a named group called X25519MLKEM768: the hybrid combination of classical X25519 elliptic-curve Diffie-Hellman and the NIST ML-KEM-768 key encapsulation mechanism. Chrome made it the default key share for most users in stages through 2024 and 2025; Cloudflare, AWS, and Google's front-ends shipped server support over the same window.

For a CISO of an Indian bank, three questions matter. What is this thing? What does it cost on the wire? What has to be true at the bank's own edge so the channel actually completes?

What the hybrid construction does

In a TLS 1.3 handshake using a single (non-hybrid) named group, the client puts one key share in the ClientHello, the server responds with one key share in the ServerHello, both sides perform the key agreement, and the resulting shared secret feeds the TLS key schedule via HKDF.

In the hybrid construction, the client puts two shares in the ClientHello — an X25519 share (32 bytes) and an ML-KEM-768 encapsulation key (1184 bytes), concatenated. The server responds with two outputs in the ServerHello — its X25519 share (32 bytes) and the ML-KEM-768 ciphertext (1088 bytes). Both sides compute their respective shared secrets, concatenate them (X25519 secret ‖ ML-KEM secret), and feed the result into HKDF-Extract as if it were a single shared secret. From there the TLS key schedule is unchanged.

The mathematical property that earns the work: for an attacker to recover the channel keys, they must break both the X25519 key exchange and the ML-KEM key exchange. Breaking only one leaves the concatenated input unrecoverable. This is the same composition principle behind "defence in depth" applied at the cryptographic primitive level.

Why hybrid, not pure ML-KEM

It would be simpler to just switch from X25519 to ML-KEM. The reason that hasn't happened is concern about ML-KEM itself. Lattice-based cryptography is younger than elliptic-curve cryptography. The lattice security assumptions are well-studied and the parameter sets were chosen with generous margins, but cryptanalytic surprises happen — the history of cryptography is littered with schemes that looked solid for a decade before breaking. Hybrid lets the deployment community gain operational experience with ML-KEM while keeping the classical fallback until enough confidence accumulates.

If lattice schemes are ever broken, hybrid deployments degrade to classical-only security — which is the security level you had before you started. If they're not, you have post-quantum security and classical security simultaneously. The cost of being wrong is bounded; the cost of being right is small.

Hybrid is not a transitional kludge. It is the load-bearing engineering choice that lets PQC deploy at internet scale without betting the security of every TLS session on a young cryptographic assumption.

What changes on the wire

The handshake grows. ClientHello picks up an extra ~1.2 KB from the ML-KEM-768 encapsulation key; ServerHello picks up an extra ~1.1 KB from the ciphertext. Total round-trip handshake payload grows by ~2.2 KB. On modern paths this is a non-event — modern TCP initial windows accommodate it without extra round trips on most connections.

The two places it bites:

  • TLS records. The ClientHello now reliably exceeds the 1500-byte MTU. TLS 1.3 fragments the ClientHello across multiple records; a small number of middleboxes don't handle this correctly. Inspect-and-rewrite proxies are the usual culprit.
  • Initial connection latency. If your end-user is on a constrained mobile network with high packet loss, the larger handshake means more opportunity for a retransmission. Measure rather than assume.

What to check at your edge

For an Indian bank running TLS termination on commercial hardware ADC, three things to verify:

  1. Vendor firmware supports the hybrid group. F5 BIG-IP, Citrix ADC, A10, NetScaler all released hybrid PQC support over the 2024–2025 window. Check the specific firmware train you run — feature parity across LTS branches lags the latest release.
  2. Cipher suite ordering and group preference. Configure the box to prefer the hybrid group when offered. Most ADCs default to the first acceptable group from the client; for browsers that put X25519MLKEM768 first, this gives PQC by default.
  3. Logging captures the negotiated group. Many ADC logs default to TLS version + cipher only. Add the named group to the log line — you cannot prove migration progress without it.

If your ADC is on a firmware line where hybrid support never shipped, that's a different conversation — the edge box has to be upgraded or replaced. Plan the upgrade now while there's still a vendor support window, not in the quarter you're reporting to the audit committee.

Read more
See the platform Back to the blog