What actually grows when you add post-quantum key exchange to a TLS 1.3 handshake?

What actually grows when you add post-quantum key exchange to a TLS 1.3 handshake?

The honest answer is bytes — and the byte count has measurable network consequences worth examining.

The migration target is hybrid key exchange: combine a classical curve with a post-quantum KEM (Key Encapsulation Mechanism) so the session stays secure if either survives. The deployed default is X25519MLKEM768, pairing X25519 with ML-KEM-768 (the standardized form of Kyber, FIPS 203).

The cost is in the key_share extension. A classical X25519 share is 32 bytes. An ML-KEM-768 public key is 1,184 bytes and its ciphertext 1,088 bytes. So the client's combined key share jumps from tens of bytes to over 1,200, and the server's response similarly. The ClientHello, which used to comfortably fit in a single network packet, now often spans multiple TCP segments.

This matters beyond bandwidth. Google's and Cloudflare's 2023–2024 measurement work found a real-world failure mode: middleboxes and TLS stacks that assumed the ClientHello fits in one packet, or that capped record sizes, broke on the larger hello — a phenomenon dubbed "protocol ossification." The fix is partly TCP-level (ensuring the larger ClientHello is handled across segments) and partly fixing intolerant implementations.

Further reading: FIPS 203 (ML-KEM); Cloudflare and Google PQC deployment reports (2023–2024); draft-ietf-tls-hybrid-design.

Bottom line: PQC inflates the key_share from ~32 bytes to over a kilobyte, pushing the ClientHello past one packet — the surprising cost isn't CPU, it's middlebox and stack intolerance to a larger hello.