Hybrid Post-Quantum TLS: Same Protocol, a 1,216-Byte Key Share

NIST finalized ML-KEM as a post-quantum key encapsulation mechanism in 2024, and the IETF is actively standardizing hybrid key agreement for TLS 1.3 ^[1]. The consequence for operators is narrow and specific: moving a connection from X25519 to X25519MLKEM768 changes how the session secret is established and inflates the handshake, while leaving most of the application-facing TLS architecture intact ^[2][3].

Start with what does not change. The TLS 1.3 flow stays recognizable: clients still send a ClientHello, servers respond with a ServerHello, certificates are still used for authentication, and the connection still transitions to encrypted application traffic ^[4]. Hybrid key exchange is not a new application protocol; it is a substitution in the cryptographic machinery underneath the connection ^[5]. Nothing above the socket needs rewriting.

What changes is the key share. The current IETF draft specifies a 1,216-byte client key exchange value for X25519MLKEM768, consisting of 1,184 bytes for the ML-KEM-768 portion and 32 bytes for X25519 ^[6]. That is 38 times the size of the X25519 value on its own ^[1], and the post-quantum component is roughly 97 percent of the total ^[2]. Handshake bytes that used to be a rounding error are now the dominant term.

The motive is harvest-now, decrypt-later. TLS 1.3 commonly uses ephemeral elliptic-curve exchange such as X25519, which holds up against currently practical classical attacks, but a sufficiently capable quantum computer could threaten the mathematical assumptions behind elliptic-curve cryptography ^[7]. An attacker can capture encrypted traffic today and retain it for later decryption ^[8]. Hybrid addresses that without a flag day: both the classical and the post-quantum components contribute to the session secret, and the draft defines the X25519MLKEM768 shared secret as the combination of the ML-KEM and X25519 shared secrets ^[9][10]. The two halves rest on different mathematics, elliptic-curve Diffie-Hellman on one side and lattices with Module Learning with Errors on the other ^[11], so the connection is not staked on a single assumption ^[12]. Cloudflare describes X25519MLKEM768 as maintaining the security provided by X25519 while adding the post-quantum component, and currently recommends it in its deployed PQC support ^[13].

The real operational tax is knowing what you negotiated. The transition brings new compatibility considerations, different implementation dependencies, and a much greater need to understand which cryptographic mechanism is actually in use ^[3]. A "PQC enabled" flag in a config file is not evidence of anything: X25519MLKEM768 pairs X25519 specifically with ML-KEM-768 ^[2], one of three parameter sets NIST defines under FIPS 203 alongside ML-KEM-512 and ML-KEM-1024 ^[14]. If your telemetry records TLS version and cipher suite but not the negotiated group, you cannot distinguish a hybrid handshake from a classical one, and you cannot see which parts of the fleet quietly fell back.

Watch the draft status. Hybrid TLS 1.3 key agreement is still being standardized ^[1], so treat the 1,216-byte figure as revision-dependent and pin which draft your libraries implement ^[6]. Then check whether your stack can negotiate ML-KEM-768 at all ^[14], and get the negotiated group into connection logs before anyone reports coverage numbers upward.