Hybrid Post-Quantum TLS Key Exchange Guide: Deploying X25519MLKEM768 without breaking the network

Browsers, CDNs and current TLS libraries already negotiate hybrid post-quantum key exchange by default, yet many enterprise networks still contain inspection proxies, load balancers and legacy servers that drop the larger handshake or quietly strip it back to classical cryptography. Hybrid key exchange combines a classical elliptic curve exchange with ML-KEM, so traffic recorded today stays confidential even if a quantum computer later breaks the classical part. This guide explains how the hybrid groups work on the wire, the current status of the IETF specifications, which components change, how to test middleboxes, and how to roll out and measure hybrid key exchange across clients, servers and service-to-service traffic. It is written for network, PKI and platform engineers and security architects. For the programme view, see the Post-Quantum Cryptography Migration Guide; this page goes deep on TLS key exchange only.

Key takeaways

• Key exchange is the urgent part. Harvest now, decrypt later means recorded TLS sessions are exposed the day the classical exchange falls, while signatures only need to be quantum-safe at the time of use.
• X25519MLKEM768 is the de facto default. Chrome moved to it (codepoint 0x11EC) in version 131 and OpenSSL 3.5 offers it in its default key shares, so the hybrid group already appears in most handshakes your edge receives.
• The specification is almost final. As checked on 27 October 2026, draft-ietf-tls-ecdhe-mlkem-04 is in the RFC Editor queue, and the framework it builds on is published as RFC 9954 (Informational).
• Middleboxes are the main failure point. The client key share grows to 1,216 bytes, the ClientHello can span more than one TCP segment, and devices that read only the first segment reset the connection.
• TLS inspection splits the problem in two. A decrypting proxy negotiates separately with the client and with the server, so post-quantum protection on one leg says nothing about the other.

How hybrid key exchange works

TLS 1.3 negotiates key exchange through the supported_groups and key_share extensions. A hybrid group is simply a new NamedGroup whose key share is the concatenation of two component shares, and whose shared secret is the concatenation of two component secrets. RFC 9954, Hybrid Key Exchange in TLS 1.3, defines that construction: the concatenated secret replaces the (EC)DHE input at the Handshake Secret step of the TLS 1.3 key schedule, no new negotiation mechanism is added, and component lengths must be fixed. If either component remains secure, the session key remains secure.

ML-KEM is a key encapsulation mechanism standardised in FIPS 203 (August 2024), with three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in increasing order of strength. The client sends an encapsulation key, the server returns a ciphertext, and both derive the same secret. See the ML-KEM Guide for the algorithm itself.

The three hybrid groups

Compare these with a classical X25519 share of 32 bytes. The draft notes that X25519MLKEM768 places ML-KEM first "for historical reasons", reversing the naming order, and it obsoletes the pre-standard Kyber codepoints 25497 and 25498. In the IANA registry all three are marked DTLS-OK and Recommended: N, which reflects IETF process rather than a security judgement.

• FIPS consequences: the draft states that for X25519MLKEM768 the ML-KEM implementation must be FIPS certified for the combined exchange to count as approved, because ML-KEM contributes the first part of the secret. For the two NIST curve groups, the ECDH implementation must be certified and ML-KEM need not be. Organisations under FIPS 140 obligations should check which component their validated module covers.
• Validation: servers must validate the client's ML-KEM encapsulation key and abort with illegal_parameter on failure; clients must check the ciphertext length. Both sides keep the RFC 8446 checks for the ECDH part, including the all-zero check for X25519.

Specification and ecosystem status

Because adoption figures move quickly, treat the 2024 Cloudflare figure as a historical marker and measure your own traffic instead (see Detection and measurement).

Where hybrid key exchange breaks

Split ClientHello and middleboxes

A ClientHello carrying a 1,216 byte key share often exceeds one TCP segment. The tldr.fail project documents servers and middleboxes that read only the first segment, fail to parse a partial message and reset the connection instead of falling back. Chrome surfaces this as ERR_CONNECTION_RESET, and network conditions can hide it in testing. Its known incompatibilities list includes a Cisco bug (CSCwj82736) and Ingress Nginx in TLS passthrough mode, with several other proxies and load balancers listed as fixed. The fix is in software: the device must keep reading until the record length in the TLS header is satisfied.

HelloRetryRequest behaviour

A client can either send the post-quantum key share immediately, or advertise the hybrid group in supported_groups and let the server request it with a HelloRetryRequest, which costs a round trip. Cloudflare reported that when connecting to origins, all tested origins handled the HelloRetryRequest approach, while sending the large share immediately caused about 0.34% of connections to fail, mostly from oversized ClientHello handling or broken HelloRetryRequest implementations.

TLS inspection

A decrypting proxy terminates the client's TLS session and opens a new one to the server. If the proxy does not support ML-KEM it will negotiate classical X25519 with the client (removing post-quantum protection on that leg even though the browser offered it) and classical again towards the server. Inspection therefore needs two checks: the client-facing and server-facing group negotiated. See the TLS Inspection Guide.

Handshake size and performance

The cost of hybrid key exchange is mostly bytes, not CPU. With X25519MLKEM768 the client sends about 1.2 KB more and the server about 1.1 KB more than with X25519 alone; with SecP384r1MLKEM1024 both directions carry 1,665 bytes. On constrained links, IoT devices and UDP-based protocols such as DTLS and QUIC, that extra size can push the first flight over packet or amplification limits. A client that offers both a hybrid and a classical share in one ClientHello sends both, and RFC 9954 notes that offering two combinations that share one ML-KEM-768 key sends that key twice. Measure handshake latency and first-flight size in the pilot rather than assuming the impact is negligible.

Downgrade and silent fallback

TLS 1.3 binds the negotiated group into the transcript, so an on-path attacker cannot simply strip the hybrid group without detection. The practical downgrade is operational: a load balancer, proxy or library update that drops hybrid groups from its configuration, after which every connection quietly uses classical exchange. ATT&CK T1689 Downgrade Attack describes the adversary behaviour; for defenders the control is configuration monitoring and handshake telemetry.

Deciding where to deploy first

Choosing a group: X25519MLKEM768 has the widest client support and is the right default for general web traffic. SecP256r1MLKEM768 suits environments where the ECDH component must be a FIPS validated NIST curve and ML-KEM validation is not yet available. SecP384r1MLKEM1024 suits policies that require the highest ML-KEM level, at the cost of a 1,665 byte share in both directions. Servers should accept more than one hybrid group and keep X25519 for clients that do not support ML-KEM.

Small versus large organisations: a small organisation using a CDN or managed load balancer may get hybrid key exchange by enabling a setting and confirming its inspection product supports it. A large organisation needs a cryptographic inventory of TLS terminators, libraries and appliances, vendor attestations, and per-segment testing. See the Cryptographic Inventory and CBOM Guide.

Implementation and rollout

1. Inventory TLS terminators. List CDNs, load balancers, reverse proxies, API gateways, ingress controllers, service mesh proxies, inspection proxies and any appliance that parses ClientHello (IPS, NDR, SNI-based firewalls). Record TLS library and version for each.
2. Get vendor statements. For each device, ask whether it supports X25519MLKEM768 on both legs, whether it handles multi-segment ClientHello, and whether its FIPS validated module covers ML-KEM. Check vendor entries against the tldr.fail list.
3. Test in a lab. Use an OpenSSL 3.5 or later client offering only the hybrid group (for example with the -groups X25519MLKEM768 option of s_client) against each terminator, and the tldr.fail test approach of sending a ClientHello split across segments. Confirm the negotiated group in the handshake output.
4. Audit the client side. Before changing servers, measure how many inbound handshakes already offer the hybrid group. Most modern browsers will.
5. Enable on a pilot ring. Turn on the hybrid group on one edge cluster or a percentage of traffic, keep classical X25519 configured as an alternative, and watch connection reset and handshake failure rates against a control group.
6. Fix the inspection path. Upgrade or reconfigure TLS inspection so both legs negotiate hybrid groups. Where the inspection product cannot, decide explicitly whether to bypass inspection for specific high-value flows or accept classical protection on that leg until it is upgraded.
7. Expand to internal and service-to-service TLS. Upgrade libraries in container base images and mesh proxies, then enable hybrid groups in mTLS profiles.
8. Roll back safely. Rollback is removing the hybrid group from the server's group list, which returns connections to X25519 without breaking clients. For managed Chrome fleets, the PostQuantumKeyAgreementEnabled policy can disable the client side temporarily while a broken middlebox is patched; set a date to remove the exception.

Where identity fits

Hybrid key exchange protects confidentiality, not authentication. Server certificates, client certificates for mTLS and workload identities still use classical signatures, and those move on a different timeline with ML-DSA and SLH-DSA. Two identity points matter now:

• Secrets in transit: bearer tokens, API keys, OAuth refresh tokens and session cookies cross TLS. If a recorded session is decrypted later, any long-lived credential inside it is exposed, so harvest now, decrypt later is also a credential problem. Shorten credential lifetimes on flows that cannot yet use hybrid key exchange.
• Machine identity platforms: service meshes and workload identity systems that issue mTLS certificates usually also control the TLS library and group configuration; plan their hybrid key exchange and later post-quantum certificate changes together. See the Post-Quantum Migration for NHIs Guide and the ML-DSA and SLH-DSA Post-Quantum Signatures Guide.

Detection and measurement

Log the negotiated group on every TLS terminator. Most proxies and load balancers can expose the key exchange group in access logs; libraries expose it through their handshake APIs. Without that field, coverage cannot be measured.

• Coverage: percentage of inbound TLS 1.3 handshakes negotiating a hybrid group, per endpoint.
• Offer rate versus accept rate: share of ClientHellos offering 0x11EC compared with share where the server selected it. A gap shows server-side configuration work.
• Inspection leg coverage: percentage of inspected sessions with hybrid groups on both the client and server legs.
• Failure signal: TCP resets and handshake failures immediately after ClientHello, compared before and after enablement, per network segment.
• Internal coverage: percentage of service-to-service TLS terminators on a library version that supports ML-KEM.
• Drift: configuration changes that remove hybrid groups from a terminator, alerted as a security event.

Framework mapping

Common failure patterns

• Assuming the browser padlock means post-quantum protection end to end. With TLS inspection or a classical-only origin behind a CDN, at least one leg may be classical.
• Enabling hybrid groups on servers without fixing middleboxes. Clients already send the large share; the failure appears when an IPS or SNI firewall in the path cannot handle a multi-segment ClientHello, and it looks like random resets.
• Leaving pre-standard Kyber codepoints enabled. 0x6399 and the obsoleted codepoints 25497 and 25498 are draft-era groups; remove them once clients have moved.
• Disabling post-quantum key agreement fleet-wide as a quick fix. The enterprise policy is a useful stopgap but often stays in place for years after the middlebox is patched.
• Dropping classical fallback. Configuring a server to accept only hybrid groups breaks older clients; keep X25519 until telemetry shows it is unused.
• Treating FIPS compliance as automatic. Under the draft, X25519MLKEM768 needs a certified ML-KEM implementation; a module validated only for ECDH does not cover it.

Practitioner checklist

• Inventory every device and library that terminates or parses TLS, with version and ML-KEM support.
• Test each against a hybrid-only client and a split ClientHello before enabling server-side support.
• Enable X25519MLKEM768 on internet-facing terminators with X25519 retained as an alternative.
• Confirm TLS inspection negotiates hybrid groups on both legs, or document the exception.
• Upgrade service-to-service libraries and mesh proxies to versions with ML-KEM in default groups.
• Log the negotiated group on every terminator and report coverage monthly.
• Remove pre-standard Kyber codepoints and alert on removal of hybrid groups from configuration.
• Check that FIPS validated modules cover the component that the chosen group requires.
• Shorten lifetimes of credentials carried over flows that remain classical.
• Re-check draft-ietf-tls-ecdhe-mlkem status and update references when it is published as an RFC.

Standards and references

• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• IETF: RFC 9954, Hybrid Key Exchange in TLS 1.3
• IETF: draft-ietf-tls-ecdhe-mlkem, Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
• NCSC: Timelines for migration to post-quantum cryptography
• OpenSSL: OpenSSL 3.5 release notes
• Google Security Blog: A new path for Kyber on the web
• tldr.fail: Split ClientHello compatibility issues
• Cloudflare: The state of the post-quantum Internet

Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Crypto-Agility Guide · How TLS Works Guide · TLS Inspection Guide · TLS Server Configuration Baseline Guide