Post-quantum TLS: X25519MLKEM768 and Merkle Tree Certificates

Post-quantum TLS in production today means one thing: the hybrid key exchange X25519MLKEM768, which Chrome, Edge and other clients already negotiate with servers that support it. It protects recorded traffic from later decryption by a quantum computer. Certificates stay classical because post-quantum signatures are large; the web's plan for them, Merkle Tree Certificates, is still experimental as of November 2026.

Why key exchange moved first

Key exchange is urgent because of "harvest now, decrypt later": traffic recorded today can be decrypted once a cryptographically relevant quantum computer exists. Shor's algorithm breaks both RSA and elliptic-curve cryptography, so the ECDHE secret that protects a 2026 TLS session would fall along with everything it encrypted.

Signatures are different. A forged signature only matters while the certificate is valid and the attacker is online, so a quantum computer built in the future cannot retroactively impersonate a server in a past connection.

The standards: ML-KEM, ML-DSA and SLH-DSA

NIST published the first three post-quantum standards on August 13, 2024, and TLS uses them in two different roles.

For TLS 1.3 key exchange, RFC 10024 (August 2026) defines three hybrid groups: X25519MLKEM768 (0x11EC), SecP256r1MLKEM768 and SecP384r1MLKEM1024. Earlier deployments used X25519Kyber768Draft00 (0x6399), a pre-standard version of Kyber that browsers have since dropped.

How hybrid key exchange works

X25519MLKEM768 runs ML-KEM-768 and X25519 side by side inside a single TLS 1.3 key share and concatenates the two results. The handshake message flow does not change; only the size of the key_share values does.

ClientHello
  supported_groups: X25519MLKEM768, X25519, ...
  key_share (X25519MLKEM768) = ML-KEM-768 encapsulation key (1184 B) || X25519 public (32 B)
                               = 1216 bytes
                                   |
                                   v
ServerHello
  key_share (X25519MLKEM768) = ML-KEM-768 ciphertext (1088 B) || X25519 public (32 B)
                               = 1120 bytes

shared secret = ML-KEM shared secret (32 B) || X25519 shared secret (32 B) = 64 bytes
                -> TLS 1.3 HKDF key schedule (unchanged)

An attacker has to break both components to recover the session keys. If ML-KEM turns out to have a flaw, the connection is no weaker than a classical X25519 one; if a quantum computer breaks X25519, ML-KEM still protects it.

The cost is bytes. Measured locally with OpenSSL 3.6.1 against a test server:

The computation itself is cheap; ML-KEM is fast on ordinary CPUs. The size is what causes trouble.

Browser and server support as of November 2026

Hybrid ML-KEM is already the default between modern browsers and modern servers.

Chrome 131 offered only one post-quantum key share at a time; Google explained that sending both Kyber and ML-KEM would make the ClientHello too large. A server that supports only the old Kyber codepoint therefore gets classical X25519 from current Chrome.

On a server, hybrid key exchange usually needs no change beyond a recent TLS library. With nginx built against OpenSSL 3.5 or later, you can set the order explicitly:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;

Check what nginx -V reports as the OpenSSL version first; many distribution packages are built against older OpenSSL 3.0 or 3.2 releases, where the X25519MLKEM768 name is unknown and nginx fails to start with this line.

Test a server from the command line (OpenSSL 3.5+):

openssl s_client -connect example.com:443 -servername example.com \
  -groups X25519MLKEM768 -brief </dev/null

Connecting to 203.0.113.10
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Signature type: ecdsa_secp256r1_sha256
Verification: OK
Negotiated TLS1.3 group: X25519MLKEM768

A server without support aborts with alert handshake failure (alert 40), because the client offered no other group. Note the Signature type: ecdsa_secp256r1_sha256 line: the key exchange is post-quantum, the authentication is not. More group and protocol tests are in cipher and protocol commands.

Large ClientHellos and middleboxes

The most common deployment problem is not cryptography but network equipment that mishandles a ClientHello larger than one packet. A ClientHello with an X25519MLKEM768 share is around 1.5 KB to 1.8 KB depending on other extensions, so with a typical 1,500-byte MTU it no longer fits in a single TCP segment or QUIC packet.

Known failure patterns:

• Firewalls, TLS-inspection proxies and load balancers that read only the first TCP segment to extract SNI, then drop or reset the connection.
• Fixed-size ClientHello buffers in older appliances, which close the connection when the message exceeds them.
• Servers that do not understand the new group must answer with HelloRetryRequest; well-behaved clients also send an X25519 share to avoid that extra round trip.

When Chrome turned hybrid key exchange on, Google gave administrators an enterprise policy (PostQuantumKeyAgreementEnabled) as a temporary switch while vendors fixed their equipment. The real fix is updating the middlebox; on the server side, make sure your load balancer or WAF firmware is current before you enable ML-KEM groups at the origin.

Why post-quantum certificates are hard

Post-quantum signatures are an order of magnitude larger than ECDSA, and a TLS handshake carries several of them. Sizes from FIPS 204 and common practice:

A typical web handshake authenticates with at least two public keys (leaf and intermediate) and five signatures: the intermediate's signature on the leaf, the root's signature on the intermediate, the server's CertificateVerify, and two or more SCTs required by Certificate Transparency. If every one of them became ML-DSA-44, that is roughly 5 × 2,420 + 2 × 1,312 ≈ 14.7 KB of authentication data, compared with under 1 KB for an ECDSA chain. A minimal self-signed certificate generated locally with OpenSSL 3.6.1 shows the same jump: 389 bytes with P-256, 785 bytes with RSA-2048 and 3,985 bytes with ML-DSA-44.

Fourteen kilobytes matters because it pushes the server's first flight past TCP's initial congestion window of ten segments (RFC 6928), adding round trips on every new connection, and it makes the middlebox problems above worse. Google's February 2026 announcement says Chrome has "no immediate plan" to add X.509 certificates with post-quantum cryptography to the Chrome Root Store.

Merkle Tree Certificates

Merkle Tree Certificates (MTCs) replace the chain of signatures with a short proof that the certificate is included in a signed Merkle tree. The design comes from the IETF PLANTS (PKI, Logs, And Tree Signatures) working group as draft-ietf-plants-merkle-tree-certs, which grew out of an earlier individual draft by David Benjamin.

Classical X.509 + CT                          Merkle Tree Certificate
--------------------                          -----------------------
Root signs Intermediate      (signature)      CA signs one tree head covering
Intermediate signs Leaf      (signature)      many certificates          (1 signature,
CT logs sign SCTs            (2+ signatures)                              fetched out of band)
Server signs handshake       (signature)
                                              Server sends: its key + inclusion proof
Server sends: chain + SCTs + CertificateVerify   (a few hashes) + CertificateVerify

Because the browser learns the signed tree heads ahead of time, the handshake carries hashes instead of large signatures, and transparency is built in: a certificate cannot exist without being in a public tree. In February 2026 Google described the plan in phases: a feasibility study with Cloudflare on real traffic, in which every MTC connection is backed by a normal X.509 certificate as a fail-safe; then bootstrapping public MTCs with existing CT log operators; then a separate Chrome Quantum-resistant Root Store that accepts only MTCs. As of November 2026 this is still experimental, and the draft is still changing.

Downgrade protection: the hard part of authentication

Adding post-quantum certificates protects nobody until browsers can refuse classical ones. An attacker with a quantum computer would forge a classical certificate from any trusted CA and impersonate a site, regardless of which certificate the real site uses. Chromium's post-quantum authentication roadmap (February 2026) therefore describes stages: add post-quantum options, let individual sites opt in to requiring them through an HSTS-like mechanism, then require a post-quantum PKI, and only far in the future require post-quantum server keys everywhere. The opt-in idea works like HSTS: a header with max-age that a browser remembers.

What to do now

Most sites need one change now, enabling X25519MLKEM768, and should not buy post-quantum certificates yet. The full list:

1. Turn on hybrid key exchange. Upgrade to a TLS library that supports X25519MLKEM768 (OpenSSL 3.5+, a current BoringSSL-based proxy or a CDN that negotiates it) and confirm with s_client -groups.
2. Check the network path. Test through your load balancer, WAF and any TLS-inspection device; that is where large ClientHellos break.
3. Keep TLS 1.3 enabled. Hybrid groups are defined only for TLS 1.3. See TLS 1.3.
4. Inventory long-lived secrets. VPNs, internal APIs and data links carrying information that must stay secret for a decade are the first places to require ML-KEM.
5. Do not buy "post-quantum certificates" for public websites yet. Keep certificate issuance automated instead, so that a future switch to MTCs or ML-DSA is a configuration change rather than a project.

For definitions, see post-quantum cryptography, ML-KEM and X25519MLKEM768.