Classical cryptography cannot simply be removed once post-quantum algorithms appear: clients and servers will need to keep speaking classical schemes for years in order to reach systems that have not yet been upgraded. That backwards compatibility is exactly what a downgrade attack exploits. An on-path attacker alters the messages exchanged between two endpoints so that each believes its peer does not support PQ at all, stripping the connection back to classical cryptography that a quantum computer can break.

Supporting the PQ primitives is therefore not enough on its own. The remaining problem is preventing an active attacker from bypassing them.

Breaking IPsec by downgrade

IPsec underpins Cloudflare IPsec, Cloudflare WAN and Magic Transit, and like every secure channel protocol — TLS included — it is exposed to the straightforward version of this attack whenever classical and post-quantum authentication are both offered. An attacker cracks the classical credentials, impersonates a party, and claims that party has no PQ support.

Several months ago, however, Cloudflare rediscovered a design flaw in IPsec that permits a more sophisticated variant, one that works no matter which authentication method is in play. It lets a quantum attacker decrypt all traffic between endpoints that are both PQ-capable. Carrying it out is comparatively difficult because it requires a quantum computation to be performed live during the handshake, rather than offline as in a harvest-now, decrypt-later attack. Whether or when it becomes feasible is unknown, but resource estimates for quantum attacks on public key cryptography have fallen sharply — enough that Cloudflare has moved its own transition deadline up to 2029.

Cloudflare worked with the IETF on an extension that adds downgrade protection to IPsec; it only helps when both peers implement it. Cloudflare has enabled beta support in Cloudflare WAN and Magic Transit, where customers can request that their account manager turn on the ipsec_downgrade_protection flag.

Where IPsec sits, and why it is being upgraded

TLS and QUIC together secure nearly all web traffic, TLS over TCP and QUIC over UDP, both at the transport layer. IPsec performs a comparable job at the IP layer, lower in the stack, which is why it is embedded so deeply in network infrastructure. Cloudflare IPsec lets organizations carry IPsec connections across Cloudflare's anycast network without costly multiprotocol label switching (MPLS) links. It is also a component of Magic Transit, where Cloudflare's anycast network sits in front of an organization's IP range, absorbs threats such as Distributed Denial of Service (DDoS) attacks, and returns the scrubbed traffic through IPsec tunnels.

Even so, IPsec keeps changing. Post-quantum key agreement has already been added, and post-quantum authentication is on a timeline roughly matching TLS and QUIC — arguably ahead of it, since the pre-shared keys IPsec commonly uses for authentication are already post-quantum. There is no reason to think the ecosystem cannot absorb this change too.

The way IPsec negotiates tunnels is worth spelling out, because the attack lives in those details. "IPsec" describes the encryption of IP packets, but before any encryption happens the two endpoints must complete an authenticated key agreement, which they do with IKEv2.

Two properties of that exchange matter here. First, each party signs only its own outbound messages rather than the full handshake transcript as TLS 1.3 does, so neither endpoint ever confirms to the other that they observed the same sequence of messages. Second, the handshake messages are encrypted: this conceals endpoint identities from the network (TLS and QUIC do not do this by default, though they can via the Encrypted Client Hello extension), and it lets the peers start using IPsec's packet fragmentation, which makes long messages — large ML-KEM key exchange messages in particular — more reliable to transmit.

Because the underlying key exchange is classical Diffie-Hellman, a quantum attacker can eventually recover the encryption key from the exchanged key shares. IKEv2 offers a defense: an intermediate exchange after the initial exchange that runs ML-KEM as the key exchange algorithm.

The compatibility rule that governs it is the opening the attacker needs. The intermediate exchange happens only when the initiator advertises support for it in the initial exchange and the responder agrees to use it. If the responder picks a classical-only key agreement, the initiator concludes its peer lacks PQ support and falls back to classical-only. Symmetrically, if the initiator never advertises PQ key agreement, the responder concludes the same about the initiator.

The attack begins with an attacker positioned between the two endpoints. Mallory, as we'll call them, intercepts the initiator's initial key exchange message, rewrites it to advertise classical-only, and forwards it to the responder. The responder now believes the initiator lacks PQ support.

Ordinarily this accomplishes little. The initiator signs the message it sent; the responder verifies the message it received. Because the two differ, signature verification fails — unless Mallory can forge a signature the responder accepts. In IKEv2 the authentication messages are also encrypted, so Mallory must derive the encryption key as well. That part the downgrade hands to them: having forced classical-only, they can point a quantum computer at the Diffie-Hellman key shares and recover the key.

What remains is the signature itself. A 2016 paper supplies the missing piece: the responder signs only its own outbound messages, so it never confirms to its peer which initiator identity it accepted. Any initiator the responder trusts can therefore complete an authentication exchange.

Make Mallory an initiator whose credentials the responder accepts, and they can sign with their own credentials. The responder finishes the connection believing it is talking to Mallory, identified as IDm. The initiator, IDi, finishes believing it is talking to the responder, IDr.

The endpoints have agreed on a key the attacker knows, and one of them has authenticated the wrong party. This is an identity-misbinding attack. A related variant needs no misbinding at all: in key-compromise impersonation, Mallory simply steals the initiator's credentials and impersonates them, eavesdropping until the responder revokes the stolen credentials. Neither attack is PQ-specific — Mallory can push the endpoints toward whatever weak key agreement method they both support.

How urgent is the quantum variant?

The quantum computation is online here: it has to finish during the handshake. That is not true of the other quantum threats to the Internet, where the work is offline — harvest-now, decrypt-later, cracking a TLS certificate. Downgrade attacks are therefore unlikely to be the first thing a cryptographically relevant quantum computer is used for, since far easier targets exist.

Still, Q-day has a non-negligible chance of arriving before classical-only has been retired from the IPsec ecosystem. Nobody yet knows how long cracking a Diffie-Hellman key agreement will take, and quantum capabilities can be expected to ramp up quickly once they exist. The IPsec PQ upgrades are already underway and take a long time to reach deployment, so it makes sense to address this while those upgrades are in flight.

Why the obvious fix falls short

Disabling classical-only key agreement — an IKEv2 configuration with an initial Diffie-Hellman exchange and no PQ key exchange after it — would close the hole. The trouble is that parameter negotiation exists for a reason: an initiator rarely knows the responder's capabilities before it connects, and vice versa.

Something HSTS-like is conceivable. Under HSTS, a client records which peers have supported the feature in a previous connection and refuses classical-only on later connections to them. That requires knowing who is connecting, which works only if the peer identifies itself. IKEv2 negotiates during the initial exchange and reveals the peer's identity only at authentication, which is too late.

More fundamentally, the real defect is what each party signs. An endpoint signs its outbound messages and not those it receives, which lets an attacker maintain a split view: one sequence of messages for the initiator, another for the responder. If the two sides confirmed they had seen the same conversation, the downgrade would be impossible. TLS 1.3 already does this — every authenticating party signs the whole handshake transcript, including the messages received from the relying party, so the relying party can confirm both sides saw the same exchange. That is the principled route.

Full transcript authentication for IKEv2

With the IPsec Maintenance (IPSECME) Working Group at IETF, we developed an IKEv2 extension, IKE_SA_INIT_FULL_TRANSCRIPT_AUTH, that gives the protocol full transcript authentication. It is on its way to RFC status. As with any feature, its use is negotiated for backwards compatibility — so the extension is itself downgradeable, except that it uses a trick to defeat that.

The mechanism has two parts:

  • Support is signaled by a notify message in the initial key exchange, and the notification is unconditional: the initiator always sends it, and the responder sends it even when the initiator did not. This departs from TLS 1.3, where the server replies to an extension only if the client requested it.
  • When the peer has signaled support, an endpoint switches to updated authentication logic: it signs the entire transcript rather than only its outbound messages, and it expects its peer to do the same.

Unconditional notification is what blocks the downgrade. Suppose Mallory strips the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification from the initiator's message but lets the responder's through. The responder reverts to the old logic while the initiator opts into the new one, so the two sign and verify different byte sequences, the authentication exchange fails, and an AUTHENTICATION_FAILURE notification is sent. Stripping the responder's notification and leaving the initiator's produces the same outcome.

Stripping both notifications sends both parties back to the old logic and would let Mallory downgrade the connection and compute the encryption key — but only if they forge a signature from the initiator and one from the responder.

Identity misbinding now demands that Mallory present an identity belonging to a different responder than the initiator intended. It is the equivalent of an initiator aiming for example.com and receiving a certificate for cloudflare.com: barring severe misconfiguration, authentication fails. Mallory can still mount the key-compromise impersonation variant if they hold the credentials of both the initiator and the responder, but with those credentials far simpler attacks are available. For IKE negotiations, Cloudflare operates only as a responder.

Enabling it

The feature sits behind a flag scoped to each customer account; customers who want to try it can ask their account team to enable it. For accounts with the flag on, the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification is sent in the IKE_SA_INIT response. The flag will be enabled for all accounts once beta testing is sufficient; it exists to cover the unlikely case of an IKEv2 initiator mishandling the new notification.

Where this leaves the ecosystem

The design flaw that permits these downgrades has been known for at least ten years. Our co-author Valery Smyslov did much of the heavy lifting in shepherding the document and spotted the trick that makes the extension downgrade-resistant. PQ migration tends to produce surprises, and ideally few of them; other cryptographic protocols in use today may well carry latent bugs that only matter in the quantum era. Cloudflare has implemented the extension on an opt-in basis, and we encourage customers to contact their account manager to test it. The wider IPsec ecosystem should consider implementing it as the draft advances through the IETF.