up:: TLS 1.3 Hybrid Key Exchange

X25519MLKEM768 and the TLS hybrid named groups

X25519MLKEM768 is the specific named key-exchange group that carries almost all of the post-quantum key exchange running on the real internet today. It pairs the classical X25519 elliptic-curve exchange with the lattice-based ML-KEM-768 key encapsulation, negotiates in the ordinary TLS 1.3 supported_groups slot, and travels on the wire as IANA codepoint 0x11EC. It is the group Chrome, Firefox, and Cloudflare ship on by default, and it is the finalized successor to the pre-standard Kyber draft group the same vendors deployed first. This note is the registry-and-history detail behind the mechanism: which groups exist, what numbers they carry, and how the ecosystem moved from Kyber to ML-KEM without breaking the handshake.

Source: IANA, “Transport Layer Security (TLS) Parameters,” Supported Groups registry, www.iana.org/assignments/tls-parameters (X25519MLKEM768, value 4588, Recommended Y).

The short version:

• X25519MLKEM768 combines classical X25519 and post-quantum ML-KEM-768 in one TLS 1.3 handshake, so the session key is safe as long as either half holds. It is a hybrid group, and it is the one you will actually see in traffic.
• Its IANA codepoint is 0x11EC (decimal 4588), and it is the only one of the three hybrid groups marked Recommended Y in the registry. That number is what travels in the supported_groups and key_share extensions.
• Two P-curve siblings exist for NIST-curve policy stacks: SecP256r1MLKEM768 (0x11EB, 4587) and SecP384r1MLKEM1024 (0x11ED, 4589), both Recommended N.
• The group is defined in RFC 10024 (formerly "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3," RFC 10024, Standards Track, August 2026), published Standards Track in August 2026, and was already widely deployed before publication.
• It replaced the earlier X25519Kyber768Draft00 group (codepoint 0x6399), now marked OBSOLETE, because the finalized ML-KEM changed enough from draft Kyber to require a fresh codepoint and a clean cutover.

Think of a TLS named group as a product code on a shelf that both the buyer and the seller have to recognize before a sale can happen. For years the shelf held only classical codes. The industry printed a first post-quantum code, X25519Kyber768Draft00, and shipped it while the recipe was still a draft. When the recipe was finalized as ML-KEM, the product was different enough that reusing the old code would have caused mismatched orders, so the industry retired that code and stocked a new one, X25519MLKEM768 under 0x11EC. Everyone reading the shelf now looks for the new code, and the old one is stamped obsolete so nobody orders it by mistake.

What is X25519MLKEM768?

X25519MLKEM768 is a hybrid TLS 1.3 key-exchange group, meaning a single negotiated group that runs two independent key agreements from different cryptographic families and folds both of their shared secrets into the session. The classical half is X25519, the elliptic-curve Diffie-Hellman function whose security a quantum computer running Shor’s algorithm would break. The post-quantum half is ML-KEM-768, the module-lattice key-encapsulation mechanism standardized in FIPS 203 and built to resist that same attack. Both run inside one handshake, and their two shared secrets are concatenated and fed into the standard TLS 1.3 key schedule, so the connection stays confidential as long as at least one of the two mechanisms remains unbroken.

The reason this matters is that it closes the harvest-now-decrypt-later window on live traffic right now. An attacker recording a classical-only session today could decrypt it once a capable quantum computer exists, and mixing ML-KEM-768 into the key schedule removes that future payoff for any session negotiated with the hybrid group. The full byte-level mechanics of how the two shares combine live in TLS 1.3 Hybrid Key Exchange; this note focuses on the named group itself and its place in the registry.

Sources: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, §1.1, csrc.nist.gov/pubs/fips/203/final, for classical key establishment being quantum-vulnerable and ML-KEM being the approved alternative (“The key establishment schemes specified in SP 800-56A and SP 800-56B are vulnerable to attacks that use sufficiently-capable quantum computers. ML-KEM is an approved alternative that is presently believed to be secure, even against adversaries in possession of a large-scale fault-tolerant quantum computer”); RFC 10024, §4.3, rfc-editor.org, for the combination (“For X25519MLKEM768, the shared secret is the concatenation of the ML-KEM shared secret and the X25519 shared secret. The shared secret is 64 bytes (32 bytes for each part)”). FIPS 203 specifies no TLS behavior.

What are the three hybrid named groups and their codepoints?

The specification defines three hybrid groups, each pairing an elliptic curve with the ML-KEM parameter set at a matching security level, and each with an assigned TLS supported_groups codepoint. The codepoint is the number that actually travels in the handshake, so knowing it lets you read a raw packet capture and confirm which group two endpoints selected.

Group	Codepoint	Classical part	Post-quantum part	Recommended
X25519MLKEM768	0x11EC (4588)	X25519	ML-KEM-768	Y
SecP256r1MLKEM768	0x11EB (4587)	secp256r1 (NIST P-256)	ML-KEM-768	N
SecP384r1MLKEM1024	0x11ED (4589)	secp384r1 (NIST P-384)	ML-KEM-1024	N

Source: IANA, “Transport Layer Security (TLS) Parameters,” Supported Groups registry, www.iana.org/assignments/tls-parameters; K. Kwiatkowski, P. Kampanakis, B. Westerbaan, D. Stebila, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,” RFC 10024, “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3,” Standards Track, August 2026 (formerly draft-ietf-tls-ecdhe-mlkem), datatracker.ietf.org.

The practical guidance is short. X25519MLKEM768 is the default across browsers and CDNs, so it dominates real captures and is the group to reach for when nothing forces a NIST curve. The P-curve siblings exist for organizations whose policy or hardware standardizes on the NIST curves, most often because a profile like CNSA 2.0 specifies P-384 and ML-KEM-1024, in which case SecP384r1MLKEM1024 is the matching group. A parser reading a capture should key off the codepoint rather than a display name, because the number is what is authoritative on the wire.

What is the draft’s standardization status?

X25519MLKEM768 comes from "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3," RFC 10024, Standards Track, August 2026, an IETF working-group document that as of mid-2026 has been IESG-approved for publication and sits in the RFC Editor queue with the state “In Progress,” so it is on the standards track and awaiting its RFC number rather than still under working-group debate. The three codepoints are already assigned in the IANA registry and carrying live traffic, which is the state that lets deployment run ahead of RFC publication.

This is a normal ordering for the IETF. A working-group draft that reaches consensus gets its code points assigned and its groups deployed before the final RFC number lands, because the technical content is stable by that stage. The companion hybrid-design document, published in July 2026 as RFC 9954 (Hybrid Key Exchange in TLS 1.3), specifies the general rule that a hybrid mechanism “facilitate[s] the establishment of a shared secret that remains secure as long as one of the component key exchange mechanisms remains unbroken,” and "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3," RFC 10024, Standards Track, August 2026 is the concrete instantiation of that rule for ECDHE plus ML-KEM.

Source: RFC 10024, “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3,” Standards Track, August 2026 (formerly draft-ietf-tls-ecdhe-mlkem), datatracker.ietf.org (Published as RFC 10024, Standards Track, August 2026); Stebila, Fluhrer, Gueron, “Hybrid key exchange in TLS 1.3,” draft-ietf-tls-hybrid-design, published as RFC 9954 in July 2026.

How did the ecosystem move from Kyber to ML-KEM?

The move happened as a clean codepoint cutover rather than an in-place upgrade, because the finalized ML-KEM was not wire-compatible with the draft Kyber that shipped first. The earlier group, X25519Kyber768Draft00, carried codepoint 0x6399 (decimal 25497) and paired X25519 with a pre-standard version of Kyber. Chrome enabled it by default in version 124 in April 2024, and Cloudflare and other CDNs supported it, which put pre-standard post-quantum key exchange on a large share of web traffic well before FIPS 203 published.

When NIST finalized ML-KEM in FIPS 203, the algorithm differed enough from the draft Kyber that a session negotiated with the old group could not simply be reinterpreted as the new one. The clean fix was a fresh codepoint. Google moved Chrome to the standardized X25519MLKEM768 group (0x11EC) starting in Chrome 131 in November 2024, and the IANA registry now marks X25519Kyber768Draft00 as OBSOLETE, so the draft group is retained only for historical parsing and should never be deployed on new systems.

Source: Google Security Blog, “A new path for Kyber on the web,” September 2024, security.googleblog.com; IANA, “Transport Layer Security (TLS) Parameters,” Supported Groups registry (X25519Kyber768Draft00, value 25497, marked OBSOLETE), www.iana.org/assignments/tls-parameters.

The lesson to carry from the transition is that a codepoint is a compatibility contract, and changing the underlying algorithm forces a new one. This is crypto-agility working as intended: the negotiation layer let the whole ecosystem retire a draft algorithm and adopt its finalized successor without changing the protocol, by swapping one number for another and marking the old one obsolete.

Where is X25519MLKEM768 deployed?

The group moved from paper to production quickly, and as of 2026 both ends of a mainstream web connection can negotiate it out of the box. The deployments that put it on real traffic:

1. Chrome and Edge ship X25519MLKEM768 on by default, having switched from the Kyber draft group starting in Chrome 131 in November 2024, so a large fraction of browser TLS handshakes now offer it.
2. Firefox added the mlkem768x25519 post-quantum key exchange and reached HTTP/3 support in Firefox 135 in February 2025.
3. Cloudflare deploys the hybrid group across its edge, having first shipped the Kyber draft group and then moved to the standardized ML-KEM group, and its at-scale testing is the source of the middlebox-size findings that shape the whole rollout.
4. Server and library support arrived through the mainstream libraries: OpenSSL 3.5 added ML-KEM, ML-DSA and SLH-DSA in April 2025, Go carries ML-KEM-768 in its standard library as crypto/mlkem, and rustls shipped experimental post-quantum key exchange in March 2024 as an X25519 hybrid, so a modern server plus a modern browser reach post-quantum key exchange on the dependency bump.

Sources: Mozilla, “Firefox 135 release notes,” February 2025, www.mozilla.org/en-US/firefox/135.0/releasenotes, for mlkem768x25519 and HTTP/3; Cloudflare, “Defending against future threats: Cloudflare goes post-quantum,” October 3, 2022, blog.cloudflare.com, for the original Kyber draft groups (X25519Kyber512Draft00 and X25519Kyber768Draft00), and Bas Westerbaan, Cloudflare, “The state of the post-quantum Internet,” March 5, 2024, blog.cloudflare.com, for the move toward the standardized group and the middlebox findings (“there are some middleboxes, load-balancers, and other software that tacitly assume the ClientHello always fits in a single packet”); OpenSSL 3.5 final release announcement, April 8, 2025, openssl-library.org (“Support for PQC algorithms (ML-KEM, ML-DSA and SLH-DSA)”); Go, crypto/mlkem package documentation, pkg.go.dev; Josh Aas, ISRG Prossimo, “The Rustls TLS Library Adds Post-Quantum Key Exchange Support,” March 26, 2024, memorysafety.org (“experimental support for post-quantum key exchange (specifically, a Kyber/X25519 hybrid scheme)”). ⚠️ None of the library sources names the X25519MLKEM768 codepoint itself; each documents the ML-KEM support that the group is built from.

The deployment reality also carries the one caveat worth repeating: enabling the group is necessary and not sufficient, because a session negotiates it only when both endpoints and every device on the path support it. A middlebox that drops the oversized ClientHello quietly forces a classical fallback, which is why confirming the negotiated group on the wire is a distinct step from turning it on. That mechanism, and the byte sizes that cause it, live in TLS 1.3 Hybrid Key Exchange.

Common misconceptions

• “X25519MLKEM768 is a new protocol.” It is one entry on the existing TLS 1.3 supported_groups menu, negotiated exactly like a classical curve. There is no new protocol version, no new extension, and a peer that does not support it falls back cleanly.
• “X25519Kyber768Draft00 and X25519MLKEM768 are the same group.” They are the pre-standard and finalized versions, built on draft Kyber and FIPS 203 ML-KEM respectively, and they carry different codepoints (0x6399 versus 0x11EC). The draft group is marked OBSOLETE in the registry, so only the standardized group belongs on new systems.
• “The P-curve groups are more secure because they use NIST curves.” They target the same security levels and exist for policy and hardware alignment, chiefly CNSA 2.0’s P-384 requirement, rather than a security advantage. X25519MLKEM768 is the registry’s Recommended choice.
• “Enabling the group means every connection uses it.” A session uses it only when both endpoints and every middlebox on the path carry it. A silent fallback to a classical group still succeeds, so the negotiated group has to be confirmed on real traffic.

Questions people ask

Which TLS group did Chrome and Cloudflare actually deploy? X25519MLKEM768, codepoint 0x11EC (decimal 4588). It combines X25519 with ML-KEM-768, it is the only hybrid group marked Recommended Y in the IANA registry, and it ships on by default in Chrome, Edge, and Firefox.

What is the codepoint, and why does it matter? The codepoint is 0x11EC, the number that travels in the supported_groups and key_share extensions on the wire. It matters because a packet capture identifies the negotiated group by that number, which is the ground-truth proof that a connection used the hybrid group rather than merely offering it.

Why did the codepoint change from the Kyber draft group? Finalized ML-KEM was not wire-compatible with the draft Kyber that shipped first, so reusing the old codepoint 0x6399 would have caused mismatched handshakes. The ecosystem assigned a fresh codepoint 0x11EC, and marked X25519Kyber768Draft00 OBSOLETE so it is retained only for parsing history.

Is X25519MLKEM768 a published RFC yet? Yes, as of August 2026. It comes from RFC 10024 (formerly "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3," RFC 10024, Standards Track, August 2026), which was published as RFC 10024 in August 2026 as of mid-2026. The codepoints are already assigned in the IANA registry and the group is deployed, which is why it carries live traffic ahead of the RFC number.

Do the P-curve groups have their own codepoints? Yes. SecP256r1MLKEM768 is 0x11EB (4587) and SecP384r1MLKEM1024 is 0x11ED (4589), both marked Recommended N. They exist for stacks bound to the NIST curves, most often by CNSA 2.0, which specifies P-384 and ML-KEM-1024.

---

Everything here is the map, given freely. When your team needs its own TLS termination points checked for which hybrid group they actually negotiate, and a rollout sequenced across every endpoint on the path, that’s the work I do.

Last verified 2026-07-27 · Updated 2026-08-27 · Maintained by Addie LaMarr, LaMarr Labs.