Post-quantum downgrade attack hybrid key exchange explained

A post-quantum downgrade attack on a hybrid key exchange is any attempt to make two peers that both support a hybrid scheme (classical ECDH combined with ML-KEM) agree on a classical-only key exchange instead. The goal is a session key that a future quantum computer could recover from recorded traffic. Whether that can work depends on how the protocol authenticates its own negotiation, and above all on local policy.

For operators of OT and critical infrastructure, this is a practical concern rather than a theoretical one. Site-to-site tunnels, edge-to-cloud links and remote access sessions often carry process data with a long useful life. A single permissive peer can quietly undo a migration that looks complete on paper. This article covers TLS 1.3 and IKEv2, the two protocols that carry most of that traffic.

Can an attacker force a VPN or TLS connection to fall back from hybrid ML-KEM to classical ECDH?

Not by tampering with the handshake alone, provided both peers implement TLS 1.3 or IKEv2 correctly, because both protocols authenticate the negotiation afterwards. The realistic risk comes from configurations that accept classical-only peers and from implementations that retry without post-quantum groups after a failure.

It helps to separate three situations that all end in a classical session:

• On-path modification. Someone rewrites the offered groups or transforms in transit. Both protocols detect this when the handshake is authenticated, as long as authentication is not already broken.
• Induced failure plus fallback. Hybrid key shares are large. If packets carrying them are dropped, whether on purpose or by a fragile middlebox, some clients retry with a smaller, classical-only offer. The protocol sees nothing wrong with that second handshake, because it is a fresh and honest negotiation.
• Policy downgrade. One side is simply configured to accept classical-only key exchange, or has not been upgraded yet. No attacker is involved, and the outcome is the same.

The size factor is concrete. The size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519) for the X25519MLKEM768 group (IETF draft-ietf-tls-ecdhe-mlkem-05, May 2026). On OT paths with reduced MTUs, old NAT devices or industrial routers, that is enough to trigger fragmentation problems that a classical handshake never ran into.

How does TLS 1.3 protect hybrid key share negotiation against downgrade?

RFC 8446 binds every handshake message into a transcript hash that is covered by the server’s CertificateVerify signature and by both Finished messages. If anyone removes a hybrid group from the ClientHello, the transcripts no longer match and the handshake fails.

Hybrid groups are ordinary named groups

draft-ietf-tls-ecdhe-mlkem defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie-Hellman) exchange. The IETF Datatracker records that it was ultimately published as RFC 10024. The ML-KEM part references NIST FIPS 203.

Because a hybrid group is negotiated through the same supported_groups and key_share extensions as X25519, it gets the same protection as any other group. RFC 8446 specifies that the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello, including any HelloRetryRequest. The revised specification says this directly: Middleboxes passing traffic between a newer client and newer server without terminating TLS should be unable to influence the handshake.

What RFC 8446 does not cover

The well-known sentinel in ServerHello.random guards against version downgrade: TLS 1.3 has a downgrade protection mechanism embedded in the server’s random value. It does nothing about group selection inside TLS 1.3. Group selection is protected only by the transcript, and the transcript only proves that both sides saw the same messages. It does not prove that the client offered a hybrid group in the first place.

Two implementation details deserve checking:

• Server preference logic. A client may send only an X25519 key share while still listing X25519MLKEM768 in supported_groups. A server that picks whichever key share happens to be present will settle on classical. A server that ranks by group preference will send a HelloRetryRequest asking for the hybrid share. Configure servers to prefer hybrid groups even if it costs an extra round trip.
• Client retry behaviour. A client that reconnects without hybrid groups after a timeout recreates the old “fallback dance” that version downgrade attacks exploited. Disable this kind of retry on any client that carries sensitive OT data.

How do you enforce a post-quantum-only policy in IKEv2 so classical-only peers are rejected?

Under RFC 9370, offer ML-KEM as a mandatory additional key exchange, without the NONE transform, so that a responder unable to perform it has no acceptable proposal. Pair this with responder-side policy that refuses any SA proposal lacking ML-KEM.

How RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem fit together

RFC 9370 (Multiple Key Exchanges in IKEv2) adds extra key exchange transform types to the SA proposal. The classical (EC)DH runs in IKE_SA_INIT, and the additional exchanges run afterwards in IKE_INTERMEDIATE messages, which keeps large post-quantum payloads out of the first unauthenticated exchange. On top of that, draft-ietf-ipsecme-ikev2-mlkem specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange.

Its author, Panos Kampanakis, states the purpose plainly: “By integrating ML-KEM into IKEv2, IKEv2/IPsec tunnels become resistant to harvest-now-decrypt-later attacks.”

Policy that actually rejects classical peers

• Initiator: list ML-KEM as the only option for the additional key exchange transform, with no NONE alternative. A responder that does not support it should answer NO_PROPOSAL_CHOSEN instead of building a classical SA.
• Responder: never select NONE for an additional key exchange, even when an initiator offers it. Being strict on the responder side matters most at hub sites that terminate many remote tunnels.
• Child SA rekeys: make sure CREATE_CHILD_SA rekeys repeat the additional key exchange. A tunnel that starts hybrid and rekeys classically has drifted into a downgrade over time.
• Data before keys: the draft notes that to guarantee data only flows over quantum-resistant keys, the peers could enforce a policy which first establishes a Childless IKE SA [RFC6023] (or a Child SA which does not encrypt any data).

The IKE_AUTH exchange authenticates the earlier messages, so stripping a proposal in transit is caught there. Explicit downgrade signalling is still being worked on: the ML-KEM draft references draft-ietf-ipsecme-ikev2-downgrade-prevention-01, 14 November 2025, which is worth following if you run mixed fleets.

How can you detect in logs that a connection negotiated a non-post-quantum key exchange?

Log the negotiated group or key exchange transforms for every session, and alert on any value that lacks an ML-KEM component. Because the selection travels in cleartext in both protocols, a passive network sensor can verify what endpoint logs report.

Endpoint and gateway logs

• TLS: record the negotiated group name (for example X25519MLKEM768 versus X25519) next to the protocol version and peer identity. Many TLS libraries expose this but leave it out of default log formats, so add it explicitly.
• IKEv2: record the primary key exchange and every additional key exchange per IKE SA and per Child SA rekey. An SA with no additional key exchange, or one where NONE was selected, is classical-only.
• HelloRetryRequest and IKE_INTERMEDIATE counts: a sudden drop in IKE_INTERMEDIATE exchanges toward a site, or a rise in handshake failures followed by successful connects, is the typical sign of fallback after induced failure.

Network-side verification

RFC 8446 requires that every ServerHello carry the key_share extension when (EC)DHE is used: Current ServerHello messages additionally contain either the “pre_shared_key” extension or the “key_share” extension, or both. Because ServerHello is not encrypted, an OT network monitor can extract the selected group without any decryption. The same holds for the SA payload in IKE_SA_INIT. Comparing this wire-level view with gateway logs catches misconfigured peers that report themselves as compliant.

Should classical fallback stay enabled during a post-quantum migration?

Keep the classical component inside the hybrid, but do not leave classical-only fallback enabled by default. Allow it only as a documented, time-limited exception for named peers that cannot yet be upgraded.

These two ideas often get mixed up. Hybrid key exchange already includes ECDH, and European guidance explicitly supports it: the EU roadmap material says to combine PQC with traditional schemes - traditional schemes must NOT be weakened, with security as long as one of the two schemes is secure. Classical-only fallback is something else. It removes the post-quantum part completely, and it is exactly the opening that a downgrade attempt needs.

Timelines set the pace. Under the proposed NIST IR 8547 timeline, quantum-vulnerable algorithms at 112-bit security strength - deprecated after 2030, disallowed after 2035 (NIST, 2025). In Europe, all Member States should start transitioning to PQC by the end of 2026. At the same time, the protection of high-risk use cases should be transitioned to PQC as soon as possible, no later than by the end of 2030. The roadmap names critical infrastructure (eg water, energy, health care, finance and transportation) as high-risk. European Commission Executive Vice-President Henna Virkkunen put it this way: “As we enter the quantum era, post-quantum cryptography is essential to ensure a high level of cybersecurity, fortifying our systems against future threats.”

A workable exception model for OT

• Inventory first. NIST advises that organizations must identify where vulnerable algorithms are used and plan to replace or update them. List every tunnel endpoint and TLS client by whether it can negotiate ML-KEM.
• Per-peer exceptions. Allow classical-only key exchange solely for named peer identities, never as a global setting, and give each exception an expiry date.
• Fix the path, not the policy. When hybrid handshakes fail because of fragmentation, adjust MTU, MSS clamping or the middlebox. Do not lower the cryptographic floor.
• Wrap what cannot change. PLCs, RTUs and embedded HMIs often cannot be upgraded at all. Putting a gateway at each end of the link moves the key exchange off those devices. Quantum Network’s QPN gateway, for example, works at Layer 3, combines a classical and an ML-KEM part into one session key, renews both handshakes every two minutes, and never falls back to unencrypted traffic after a line failure.

A one-way ratchet works well: once a peer has negotiated a hybrid key exchange successfully, remove its classical-only exception for good. Any later classical session from that peer then shows up as an anomaly worth investigating, not as normal behaviour.