Post-quantum TLS is already in your handshake, but it only solves half the problem

The short version: the key exchange half is essentially solved. The signature half is not.

The threat model is not “quantum computers are coming”

The actual threat is called harvest now, decrypt later. Someone records your TLS traffic today and stores it, then decrypts it later, once a quantum computer can do the job.

What makes it nasty is that it does not need to succeed now. If a session recorded today protects something that must stay secret for ten years, then a quantum computer arriving within those ten years turns today’s recording into a win.

So this is not a “deal with it when quantum computers show up” problem. The question is: how long does the information you are protecting need to stay secret? Medical records, identity documents, long-lived keys — those have decades-long confidentiality windows and are worth handling now.

NIST finalised three standards in 2024

• FIPS 203 — ML-KEM: key encapsulation, the replacement for things like ECDH
• FIPS 204 — ML-DSA: digital signatures
• FIPS 205 — SLH-DSA: another signature family, hash-based; larger signatures, more conservative assumptions

What browsers and CDNs did: hybrid

The default in mainstream browsers and CDNs today is a hybrid group like X25519MLKEM768 — the classic elliptic curve and the post-quantum KEM are run both at once, and the two outputs are combined into the key material.

The hybrid choice is deliberate, not laziness during a transition:

• Post-quantum algorithms have a far shorter history of analysis; nobody can promise there is no new attack in ten years
• The classical algorithm is still safe today even if it will eventually fall
• Run both, and if either one holds, the session holds

The cost is one extra KEM computation per handshake. Against what it buys, that is noise.

Why “only half”

Key exchange negotiates an ephemeral secret. The change lives entirely inside the handshake: the client and the server each compute something, and nothing above notices. So when browsers and CDNs upgrade, you get it for free.

Signatures are different. Every link in the certificate chain has to move to a post-quantum algorithm, and post-quantum signatures and public keys are much larger — signatures run past 2 KB, public keys are in the kilobyte range. Two consequences follow:

1. Certificate chains get fat. A three-link chain can grow by several kilobytes just in signatures and public keys.
2. A handshake can exceed the capacity of a single TLS record, triggering fragmentation or hitting the buffer limits of some middlebox.

The second one is the worst kind of operational problem: nothing is wrong, until one day you swap a CA or add an intermediate and suddenly some clients cannot connect.

What a site owner should do now

• If you sit behind a CDN or cloud provider, you already get the key exchange half for free — do nothing
• What to start watching is certificate chain length. Prefer TLS 1.3, and drop intermediates when you can
• If you terminate TLS yourself, confirm your library and version support the ML-KEM hybrid groups, then turn it on
• Do not change your signature algorithms for post-quantum reasons yet — the ecosystem (CAs, OCSP, client validation) is not ready

My own call: nothing urgent this round, but “certificate chain length” goes on the inspection list. It is the classic “looks perfectly fine, then one day the handshake fails”, and that kind of problem costs far more to diagnose than to prevent.