The question most TLS infrastructure owners ask, once they have accepted that the key exchange layer must change, is how much else breaks. The honest answer: less than you probably assume. Post-quantum TLS migration changes two things, the key exchange algorithm and, eventually, the certificate signature algorithm. The record layer, the handshake state machine, session resumption, and OCSP stapling are structurally unchanged. That distinction matters operationally. An engineer who understands what is not changing is in a much better position to sequence the migration than one who treats post-quantum TLS as a protocol replacement.
This article covers both tracks: what changes (with specific byte counts, not vague descriptions), and what does not. For the certificate chain migration in detail, see the PKI migration planning guide. For ML-KEM in VPN and tunnel contexts beyond TLS, see the post-quantum VPN analysis.
What TLS 1.3 Currently Uses and Which Parts Are Quantum-Vulnerable
TLS 1.3 (RFC 8446, August 2018) uses the following cryptographic primitives in a standard handshake:
- Key exchange: ECDH with X25519 or ECDH with P-256/P-384, negotiated via the key_share extension in ClientHello
- Authentication: RSA-PSS (2048-bit minimum) or ECDSA P-256/P-384, bound to the server's certificate chain
- Record layer: AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305
- Key derivation: HKDF-SHA-256 or HKDF-SHA-384
The quantum-vulnerable components are the key exchange (ECDH) and the authentication (RSA/ECDSA in certificates). The record layer and HKDF components are quantum-safe at their current key lengths. AES-256 retains 128-bit post-Grover security. NIST IR 8547 (November 2024) explicitly retains AES-256 and HKDF-SHA-384 in its post-quantum algorithm inventory [VERIFIED: IETF RFC 8446; NIST IR 8547, doi:10.6028/NIST.IR.8547]. The post-quantum migration is about the asymmetric layer. AES-256-GCM does not need to change.
One precondition worth flagging for organisations still running TLS 1.2 with RSA key exchange cipher suites: TLS 1.2 RSA-based cipher suites allow the server's RSA certificate key to be used for both authentication and key transport in the same handshake, no forward secrecy. TLS 1.3 eliminated RSA key transport entirely; all TLS 1.3 key exchange is (EC)DHE. Before or alongside the post-quantum migration, organisations on TLS 1.2 RSA key transport should migrate to TLS 1.3 ECDHE as a first step [VERIFIED: RFC 8446, elimination of RSA key transport; NIST SP 800-52 Rev. 2].
What Changes in the ClientHello and ServerHello
The key_share extension in the TLS 1.3 ClientHello carries the client's key exchange material. For X25519, that is 32 bytes. In a post-quantum hybrid deployment using X-Wing (RFC 9496, X25519 + ML-KEM-768), the ClientHello key share becomes 1,216 bytes: 32 bytes for the X25519 component and 1,184 bytes for the ML-KEM-768 public key [VERIFIED: IETF RFC 9496, Section 3; NIST FIPS 203, ML-KEM-768 sizes]. For ML-KEM-768 standalone (no X25519 component), it is 1,184 bytes.
The ServerHello key share changes correspondingly. In X25519, the ServerHello carries a 32-byte Curve25519 point. In X-Wing, the ServerHello carries the 1,120-byte combined ciphertext: 32 bytes of X25519 material and 1,088 bytes of ML-KEM-768 ciphertext [VERIFIED: RFC 9496; NIST FIPS 203]. The client runs ML-KEM.Decaps on the ML-KEM-768 component to recover its shared secret, then combines it with the X25519 shared secret via the X-Wing HKDF construction. The semantics of the handshake are unchanged: key exchange completes before the Finished message, and the session keys derive from the combined transcript.
Total additional handshake bytes from the key exchange change alone: approximately 2,272 bytes, split between the ClientHello (+1,184 bytes for the ML-KEM-768 component) and ServerHello (+1,088 bytes for the ML-KEM-768 ciphertext). The significance for packet sizing and latency is covered below.
On codepoints: the IETF TLS WG hybrid key exchange draft (draft-ietf-tls-hybrid-design) registers NamedGroup codepoints for hybrid key shares. Use the IANA-registered codepoints. Libraries that implemented hybrid TLS before registration was finalised used provisional codepoints that require updating when the draft publishes as an RFC [VERIFIED: IETF draft-ietf-tls-hybrid-design, Section 5; RFC 9496].
Certificate Chain Changes: Authentication Is a Separate Migration Track
Certificate chain migration is independent of key exchange migration. You can deploy hybrid key exchange on TLS servers and clients, providing immediate protection against HNDL attacks on session keys, without touching the certificate chain. The server can use an X-Wing ClientHello/ServerHello key exchange with an existing ECDSA or RSA certificate for authentication. That is a valid intermediate configuration and is the recommended Step 1 for most organisations [VERIFIED: NIST NCCoE SP 1800-38C, migration sequencing; NIST FIPS 204, ML-DSA].
When certificate migration does proceed, the size implications are substantial. ML-DSA-65 (FIPS 204, security Level 3): public key 1,952 bytes, signature 3,309 bytes. ML-DSA-87 (Level 5): public key 2,592 bytes, signature 4,627 bytes. For comparison: ECDSA P-256 public key is 64 bytes; ECDSA P-256 signature is 64 bytes [VERIFIED: NIST FIPS 204, doi:10.6028/NIST.FIPS.204].
A three-certificate chain (server, intermediate, root CA) with ML-DSA-65 signatures contains approximately 3 x (1,952 + 3,309) = 15,783 bytes of key and signature material before certificate structural fields, Subject Alternative Names, and extensions. An equivalent ECDSA P-256 chain totals approximately 3 x (64 + 64) = 384 bytes of key and signature material. The increase is a factor of roughly 41 for ML-DSA-65, or higher for ML-DSA-87.
SLH-DSA (FIPS 205, hash-based signatures) offers an alternative for CA certificates. SLH-DSA-SHA2-128s has a public key of 32 bytes but a signature of 7,856 bytes. SLH-DSA-SHA2-128f: public key 32 bytes, signature 17,088 bytes [VERIFIED: NIST FIPS 205, doi:10.6028/NIST.FIPS.205]. SLH-DSA's security rests on SHA-2/SHA-3 alone, making it the conservative choice for long-lived root CA certificates where the signature is verified infrequently. For server certificates under frequent verification, ML-DSA-65 is the practical choice. See the PKI migration guide for the full CA hierarchy migration sequence.
What Does Not Change in a Post-Quantum TLS Deployment
The TLS 1.3 record layer does not change. Once session keys are established via the hybrid KEM handshake, the encryption of application data uses AES-256-GCM or ChaCha20-Poly1305 exactly as it does today. The post-quantum migration secures the key establishment that produces those session keys. The record layer cipher is already quantum-safe at AES-256 [VERIFIED: RFC 8446, record layer; NIST IR 8547, AES-256 retention].
The handshake protocol state machine does not change. The sequence, ClientHello, ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished, is structurally identical. The content of the key_share extensions changes; the protocol roles and the handshake transcript construction do not. TLS libraries with pluggable key exchange and signature algorithm support can add ML-KEM and ML-DSA without rewriting the core handshake logic. The OQS-OpenSSL integration with OpenSSL 3.x demonstrates this in practice: the existing TLS 1.3 implementation is extended, not replaced [VERIFIED: RFC 8446, handshake state machine; Open Quantum Safe project].
Session resumption (TLS 1.3 session tickets and pre-shared keys, RFC 8446 Section 2.2) is structurally unchanged. Session ticket encryption remains AES-based at the server. Resumed sessions inherit the security of the original handshake: if that handshake used PQ-safe key exchange, the resumed session has PQ-safe key material. One operational note: session tickets issued before the PQ migration (from ECDH-only handshakes) should be invalidated after deployment. Resumed sessions from pre-migration tickets carry session keys established without ML-KEM [VERIFIED: RFC 8446, Section 2.2].
OCSP (RFC 6960) and OCSP stapling (RFC 6066 TLS status_request) do not change as protocols. The OCSP response is signed by the OCSP responder's certificate, which will migrate to ML-DSA as part of the certificate ecosystem migration. When that migration completes, stapled OCSP responses will carry ML-DSA signatures and will be larger. The OCSP protocol, the stapling mechanism, and the revocation checking logic are otherwise unchanged [VERIFIED: IETF RFC 6960; IETF RFC 6066; NIST FIPS 204].
Packet Size and Latency: What to Measure Before You Deploy
The combined handshake size impact of hybrid key exchange alone, assuming ECDSA certificates remain unchanged:
| Element | Classical TLS 1.3 | X-Wing hybrid TLS |
|---|---|---|
| ClientHello key_share | 32 bytes (X25519) | 1,216 bytes (X-Wing) |
| ServerHello key_share | 32 bytes | 1,120 bytes |
| Net key exchange addition | N/A | +2,272 bytes |
| Server certificate signature (ECDSA P-256) | 64 bytes | 64 bytes (unchanged at Step 1) |
| Server certificate signature (ML-DSA-65) | N/A | 3,309 bytes (when Step 2 completes) |
[VERIFIED: NIST FIPS 203, ML-KEM-768 sizes; RFC 9496, X-Wing component sizes; NIST FIPS 204, ML-DSA-65 sizes]
The typical TCP initial congestion window (initcwnd) on a modern Linux server defaults to 10 segments of 1,460 bytes each, approximately 14,600 bytes [INFERRED: representative modern Linux TCP default; precise value depends on kernel configuration and server settings]. The 2,240 bytes of additional key exchange material from X-Wing fits within the initcwnd on most configurations without forcing an additional round trip. The risk arises when certificate migration to ML-DSA is complete: a three-certificate ML-DSA-65 chain adds roughly 15 KB of key/signature material, and combined with the key exchange addition the total handshake may exceed the initcwnd on some paths, adding one RTT.
For deployments where TLS handshake latency is operationally critical, high-frequency trading, real-time industrial systems, CDN-served applications with high connection rates, the assessment sequence is: instrument current handshake sizes using network capture, model the projected sizes with hybrid key exchange and eventual ML-DSA certificates, measure the TCP initcwnd on your specific network path, then assess whether TCP Fast Open (RFC 7413) is viable to offset any additional RTT [VERIFIED: IETF RFC 7413, TCP Fast Open].
QUIC deployments (RFC 9001 uses TLS 1.3 as its security layer) face an additional constraint. QUIC Initial packets have a minimum size of 1,200 bytes (RFC 9000) and typical maximum datagram sizes of approximately 1,280 bytes for IPv6 compatibility. ML-KEM-768 key material in the QUIC Initial may require multiple datagrams for the ClientHello, which QUIC natively supports, but which adds implementation complexity. Test post-quantum QUIC with both IPv4 and IPv6 paths and with your specific QUIC implementation (Chromium, quic-go, quinn) before production deployment [VERIFIED: IETF RFC 9001; IETF RFC 9000].
Deployment Sequencing: Key Exchange First, Certificates Second
The operational recommendation for most organisations is a three-step sequence.
Step 1: Deploy hybrid key exchange. Enable X-Wing (or P-384 + ML-KEM-1024 for NSS environments) on TLS servers and clients. This secures new connections against HNDL attacks on session keys immediately, before certificate migration is complete and without any CA dependency. On modern TLS stacks with OQS-OpenSSL or BoringSSL hybrid support, this is deployable in weeks. No certificate changes are required. Cloudflare ran hybrid PQC in production from 2023, initially with a pre-standardisation Kyber variant and updated to ML-KEM post-FIPS 203 publication [VERIFIED: Cloudflare, "Post-quantum cryptography for all," 2023; Open Quantum Safe project].
Step 2: Migrate server certificates to ML-DSA. This requires CA support for ML-DSA certificate issuance, client TLS library support for ML-DSA signature verification, and browser and OS trust store updates for ML-DSA root CAs. As of knowledge cutoff (August 2025), no major public CA had offered commercial ML-DSA certificate issuance in production [ASSUMED: verify whether DigiCert, Sectigo, GlobalSign, or Let's Encrypt has launched ML-DSA issuance as of June 2026]. Step 2 runs on a longer timeline governed by ecosystem maturity, not by your internal deployment readiness.
Step 3: Retire classical key exchange from supported cipher suites once the client base is confirmed PQC-capable. This is the final step and the one with the longest lead time for consumer-facing services [VERIFIED: NIST NCCoE SP 1800-38C, migration sequencing].
The deployment sequencing argument is the most operationally important point in this article. Many organisations are paralysed by the certificate migration dependency, waiting for CA support before beginning any PQC work. Step 1 has no CA dependency. BoringSSL has shipped hybrid TLS in Chrome since 2023 [ASSUMED: verify that current Chrome and BoringSSL releases use FIPS 203 ML-KEM-768 and not the pre-standardisation Kyber variant; confirm as of June 2026]. The HNDL protection from key exchange migration is available today. Waiting for Step 2 to become available before starting Step 1 is the wrong sequence.
Assess your specific TLS infrastructure readiness with the QSECDEF TLS Migration Assessment.
For the underlying KEM primitives that make post-quantum key exchange work, see Key Encapsulation Mechanisms Explained for Security Architects. For the certificate authority migration sequence, see the PKI migration planning guide.
