Mitigating Quantum Downgrade Attacks in IPsec with Full Transcript Authentication

Mitigating Quantum Downgrade Attacks in IPsec with Full Transcript Authentication Cloudflare has collaborated with the IETF IPsecME Working Group to develop and beta-test a new IKEv2 extension, IKE_SA_INIT_FULL_TRANSCRIPT_AUTH. The mitigation prevents quantum-capable on-path attackers from forcing endpoints that support post-quantum cryptography to fall back to vulnerable classical algorithms. Maintaining backwards compatibility with classical cryptography exposes IPsec to downgrade attacks by on-path quantum attackers. The vulnerability stems from IKEv2 only signing outbound messages rather than the full handshake transcript, enabling split-view and identity-misbinding attacks. The IETF draft extension introduces full transcript authentication with unconditional notifications to stop downgrade attempts. Cloudflare has deployed beta support for the extension across Cloudflare WAN and Magic Transit under an account feature flag. Quantum Transition and Downgrade Risks Migrating Internet infrastructure to post-quantum (PQ) cryptography requires replacing algorithms like Diffie-Hellman with schemes like ML-KEM. Because transitioning every endpoint will take years, systems must preserve backwards compatibility with classical cryptography. However, this creates an opportunity for on-path attackers to alter handshake messages, convincing capable endpoints that their peer only supports classical cryptography. With resource estimates for quantum attacks falling rapidly, Cloudflare has advanced its post-quantum transition timeline to 2029. Protocol Flaw in IKEv2 Handshakes In IKEv2, endpoints run an initial exchange with classical Diffie-Hellman key shares and may optionally conduct an intermediate exchange for post-quantum key agreement. Handshake messages are authenticated during a subsequent exchange. A structural flaw exists because each party signs only its own outbound messages instead of the entire transcript. Consequently, neither endpoint verifies that both observed the identical exchange sequence, creating a split-view vulnerability if an attacker intercepts and modifies the initial parameters. Mechanics of the Quantum Downgrade Attack An active attacker with a real-time quantum computer can strip post-quantum advertisements from the initiator's initial message. Because classical Diffie-Hellman is negotiated, the attacker can break the key shares to recover the encryption key for subsequent messages. By exploiting the lack of mutual identity binding demonstrated in prior research, the attacker can supply their own trusted credentials to sign the altered message, causing the responder to accept the connection under a mismatched identity while traffic remains decryptable. Full Transcript Authentication Extension To resolve the underlying design flaw, Cloudflare and the IETF IPSECME Working Group authored an extension called IKE_SA_INIT_FULL_TRANSCRIPT_AUTH. It requires endpoints to authenticate the entire handshake transcript, aligning IKEv2 with modern protocols like TLS 1.3. The extension resists downgrade tampering using unconditional notification: if an attacker drops the notification from one direction, a transcript mismatch triggers an authentication failure; dropping it from both would require simultaneously forging valid signatures for both the initiator and responder. Deployment and Beta Availability Cloudflare has implemented the extension in beta across Cloudflare WAN and Magic Transit, where it functions in responder mode. Customers can enable protection by requesting that account teams activate the ipsec_downgrade_protection feature flag. While the extension proceeds along the IETF RFC track, Cloudflare plans to enable the protection by default following broader ecosystem testing.

Cloudflare与IETF合作推出IKEv2扩展，防范针对IPsec的量子降级攻击 为了在后量子密码迁移期间维护向后兼容性，IPsec存在被在路攻击者利用量子计算实施降级攻击的风险。Cloudflare与IETF合作开发了IKEv2全量握手记录认证扩展，并在其WAN与Magic Transit等产品中开启Beta测试，从根本上解决由于单向消息签名导致的协议缺陷。 为保持向后兼容，同时支持传统与后量子加密的协议易遭受在路攻击者迫使其降级至传统弱加密的降级攻击。 IKEv2协议存在仅对各自发送消息签名而非对完整握手记录签名的设计缺陷，容易遭到结合身份错误绑定的降级攻击。 该量子攻击难度较高，需要量子计算机在握手过程中实时在线计算出Diffie-Hellman密钥，但量子攻击算力门槛正加速下降。 Cloudflare与IETF IPSECME工作组合作推出了IKE_SA_INIT_FULL_TRANSCRIPT_AUTH扩展，通过完整记录签名和无条件通知机制阻止降级。 Cloudflare已在其IPsec产品中提供该功能测试，客户可通过账户经理开启ipsec_downgrade_protection标志。 后量子迁移中的向后兼容与降级风险 随着量子计算威胁临近，互联网正向ML-KEM等后量子加密（PQ）机制迁移。但全面升级需要数年时间，现代设备仍须保留对传统加密的支持以保证向后兼容。这种共存状态催生了降级攻击的风险：在路攻击者可篡改通信，使终端误以为对方不支持后量子加密，从而被迫回退至可被量子计算机攻破的传统算法。 IPsec与IKEv2握手设计缺陷剖析 IPsec在IP层运作，其加密密钥协商依赖IKEv2协议。在IKEv2设计中，各方在认证交换阶段仅对自身向外发送的消息进行签名，而非像TLS 1.3那样签署完整的握手记录。这导致通信双方无法确认是否观察到了完全一致的消息序列，给攻击者制造握手分歧创造了条件。 量子在线攻击与身份错误绑定机制 攻击者在拦截协商并伪造为仅传统模式后，可利用量子计算机实时在线破解Diffie-Hellman密钥。由于IKEv2响应方不会向对端确认其所接受的发起方身份，若攻击者自身拥有受信任凭证，即可利用自己的签名完成身份错误绑定攻击，让两端协商出攻击者掌握的密钥，达成流量解密。 全记录认证扩展与防降级机制 单纯禁用传统加密或使用类似HSTS的机制在IKEv2的早期协商阶段均不够完善。Cloudflare与IETF IPSECME工作组合作推进了名为IKE_SA_INIT_FULL_TRANSCRIPT_AUTH的扩展规范。该扩展通过强制签署整个握手记录，并采用“无条件通知”设计，确保一旦攻击者篡改或丢弃通知，两端认证逻辑即刻失配并报错终止连接。 部署落地与生态推进 该草案即将成为正式RFC标准。Cloudflare已在Cloudflare WAN与Magic Transit产品中部署该扩展的Beta支持，客户可联系客户经理开启功能标志进行测试。在充分验证发起方兼容性后，Cloudflare计划向所有账户默认推广该防护。

For Birthday Week, Cloudflare is helping one of the Internet’s core security protocols develop stronger protections against quantum downgrade attacks. To protect our customers and the Internet at large, we worked with the IETF to develop a mitigation against downgrade attacks on IPsec, which we’ve implemented and made available in beta across our IPsec products. The world is racing to build the first generation of quantum computers. These new machines hold great promise, but they also create a new threat: early quantum computers will be capable of cracking cryptography we've relied on for secure communication. To address this, it is necessary to migrate to *post-quantum* (PQ) cryptography: cryptography we believe even quantum computers cannot break. Diffie-Hellman key agreement will have to be replaced by PQ key agreement mechanisms such as ML-KEM; classical signature schemes, like ECDSA and RSA, will have to be replaced by PQ schemes such as ML-DSA; and so on. The PQ migration is well underway, and we’re helping the migration along by making post-quantum encryption the default in our [products](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-cloudflare-products/), open-sourcing part of our [internal cryptography discovery tool](http://blog.cloudflare.com/ai-driven-cryptography-discovery), launching new [post-quantum visibility features](http://blog.cloudflare.com/post-quantum-visibility), and leading the way in the web’s migration to post-quantum certificates. Still, it will take years before all clients and servers on the Internet have been upgraded to post-quantum cryptography. In the meantime, it will be necessary for modern devices to maintain support for classical cryptography in order to connect with today’s endpoints. The need for backwards compatibility creates its own risk. In a **downgrade attack**, an on-path attacker between a client and server tricks the endpoints into using weaker crypto than they support. It does so by manipulating the messages sent between client and server, making it appear to one party that its peer does not support PQ at all. In other words, a downgrade attack eliminates the protection provided by PQ cryptography by downgrading the victims back to classical, so it can be attacked by a quantum computer. What this means is that merely adding support for the cryptographic primitives themselves is not sufficient to head off the quantum threat. The next frontier in the PQ migration is to prevent active attackers from *bypassing* PQ by downgrading the connection. In this post, we focus on the IPsec protocol, a central component of a variety of Cloudflare products, namely Cloudflare IPsec, Cloudflare WAN, and Magic Transit. Like all secure channel protocols, including TLS, IPsec is vulnerable to the following simple downgrade attack as long as both classical and post-quantum authentication are supported. An attacker can impersonate a party by cracking its classical credentials and can pretend the party doesn't support PQ. However, several months ago, we discovered — or rather rediscovered, as we'll explain — a design flaw in IPsec that admits a more sophisticated attack that works regardless of which authentication method is used. The vulnerability allows a quantum attacker to decrypt all traffic between PQ-capable endpoints. The attack is relatively hard to pull off, as it requires a quantum computation to be carried out in real time during the protocol handshake. (This is different from a *harvest-now, decrypt-later* attack, where the quantum computation is entirely offline.) We don't yet know if and when this attack will be feasible, but recent trends give us ample reason to be cautious: at the time of writing, resource estimates for quantum attacks on public key cryptography have decreased dramatically, leading Cloudflare [to move up our transition deadline to 2029.](https://blog.cloudflare.com/post-quantum-roadmap/) To inoculate IPsec to this threat, we helped the IETF develop [an extension](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/) that adds a downgrade protection mechanism to IPsec. Both parties must support this extension for it to be effective: for our part, Cloudflare has rolled out beta support in Cloudflare WAN and Magic Transit, which customers can now enable by requesting the account managers to turn on the `ipsec_downgrade_protection` flag for their accounts. We hope to see the rest of the IPsec ecosystem follow suit in short order. Frequent readers of the Cloudflare blog are likely already familiar with the TLS and QUIC protocols. Between them, TLS/QUIC secure virtually all the web traffic transiting the Internet today. Both operate at the transport layer of the network stack: TLS runs over [TCP](https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/), while QUIC runs over [UDP](https://www.cloudflare.com/learning/ddos/glossary/user-datagram-protocol-udp/). IPsec serves a similar function, but operates at the IP layer. Because IPsec operates at an even lower layer of the network stack than TLS and QUIC, it is deeply rooted in modern network infrastructure. Cloudflare IPsec allows organizations to extend their IPsec connections over Cloudflare’s global anycast network without expensive multiprotocol label switching ([MPLS](https://www.cloudflare.com/learning/network-layer/what-is-mpls/)) connections. IPsec is also part of Cloudflare’s [Magic Transit](https://developers.cloudflare.com/magic-transit/) product. With Magic Transit, Cloudflare’s global anycast network sits in front of an organization’s IP range to shield it from attacks and threats like Distributed Denial of Service (DDoS) attacks, and then hands the scrubbed traffic back to the organization via IPsec tunnels. Despite being so deeply rooted in today's Internet infrastructure, the IPsec protocol continues to evolve. It has seen many important upgrades in the past several years, including the addition of [PQ key agreement](https://blog.cloudflare.com/post-quantum-ipsec/). IPsec is also on track to adopt PQ authentication on about the same timeline as TLS/QUIC. (In fact, IPsec is actually further along, depending on how it's configured. A pre-shared key is frequently used for authentication in IPsec, and this is already fully PQ!) This suggests that the IPsec ecosystem is more than capable of adapting to shifting threats. Let's now take a peek into the protocol details that are relevant to the downgrade attack. "IPsec" refers to the mechanism used to encrypt IP packets. Before encryption can begin, the endpoints must first perform an **authenticated key agreement**. They do so using the [IKEv2](https://datatracker.ietf.org/doc/rfc7296/) protocol. IKEv2 typically has two phases, called **exchanges**. In the initial exchange, the **initiator** advertises the parameters it supports and sends a Diffie-Hellman key share. The **responder** completes the initial exchange by telling the initiator which parameters it selected and sending its own key share. After the initial exchange, the initiator and responder derive an encryption key from the key shares and encrypt all subsequent exchanges. The key shares are not yet authenticated, meaning each endpoint has no way of knowing where the key share came from. This is accomplished in the authentication exchange, in which the initiator identifies itself to its peer and sends a signature of its key share and advertised parameters. The responder uses the identity to resolve the initiator's credentials and verifies the signature before accepting the new connection. The responder does the same in the authentication message it sends in reply. One crucial detail to point out here: **each party only signs its outbound messages**, rather than the entire handshake transcript, as in more modern protocols like TLS 1.3. This means the authenticating party never confirms to the relying party that they've observed the same sequence of messages. This will be crucial for the attack. Encrypting handshake messages has two purposes. First, it hides the identity of the endpoints from the network. (TLS/QUIC don't have this feature by default, but can enable it using the [Encrypted Client Hello](https://datatracker.ietf.org/doc/rfc9849/) extension.) Second, it allows the endpoints to begin using IPsec's packet fragmentation mechanism, making transmission of long messages over multiple packets more reliable. (This is especially relevant to handling large ML-KEM key exchange messages.) This protocol relies on classical Diffie-Hellman key exchange, meaning a quantum attacker will eventually be able to derive the encryption key from the exchanged key shares. To mitigate this threat, [IKEv2 includes an option](https://datatracker.ietf.org/doc/rfc9242/) to run an **intermediate exchange** following the initial exchange using ML-KEM as the key exchange algorithm: **Backwards compatibility.** Crucially, this exchange is only performed if the initiator advertises support for it in the initial exchange and the responder agrees to use it. This allows for backwards compatibility with endpoints that don't yet support PQ. In particular, if the responder selects a classical-only key agreement, then the initiator will assume the responder doesn't support PQ and fall back to classical-only. Likewise, if the initiator doesn't advertise support for PQ key agreement, then the responder will assume the initiator doesn't support it. Let's think about how to exploit this parameter negotiation behavior. We'll start with a simple idea that doesn't quite work, and see what it takes to make it work. Suppose there's an attacker between the endpoints — let's call them Mallory — who has a quantum computer. Mallory can make it appear to the responder that the initiator doesn't support PQ by intercepting the initiator's initial key exchange message, rewriting it to advertise classical-only, and forwarding the modified message to the responder. This would cause the authentication exchange to fail. The initiator signs the message it *sent*, but the responder verifies the message it *received*. Since the message received is different from the message sent, verification of the signature would fail, unless the attacker also manages to forge a signature that the responder would accept. That's not all, however: in IKEv2, the authentication messages are *encrypted*, which means Mallory also needs to compute the encryption key. But this is precisely what the downgrade attack enables: Mallory has already convinced the endpoints to fall back to classical-only, and they can use their quantum computer to recover the encryption key from the Diffie-Hellman key shares. Still, there's no obvious way to forge a signature from the honest initiator, unless Mallory has compromised the initiator's authentication key. [A paper from 2016](https://eprint.iacr.org/2016/072) observes the following: because the responder only signs its own outbound messages, it doesn't actually confirm to its peer which initiator identity it accepted. This means the responder will accept an authentication message from *any* initiator it trusts, not just the initiator of the connection. Suppose Mallory themself is an initiator whose credentials the responder will accept. In this case, Mallory can produce a valid signature using *their own credentials*. The responder will complete the connection, believing it's talking to Mallory, who is identified by `ID` in the figure below. Meanwhile, the initiator (_m`ID`) will complete the connection, believing it's talking to the responder (_i`ID`):_r This is a kind of **[identity-misbinding](https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24)** attack: the endpoints have both accepted an encryption key known to the attacker, but one endpoint has authenticated the wrong entity. More variants of this attack are possible. For example, in a [**key-compromise impersonation**](https://cryptologie.net/posts/key-compromise-impersonation-attacks-kci/) attack, Mallory would just steal the initiator's credentials and impersonate the initiator directly, allowing them to eavesdrop until the responder has revoked the stolen credentials; this kind of attack does not require identity misbinding. These attacks are also not PQ-specific: Mallory can force the endpoints to use the weakest key agreement method they both support. The main difficulty with the quantum variant of this attack is that the quantum computation is online, meaning it must be carried out during the attack before the handshake completes. This is in contrast to other quantum threats to the Internet, where the computation is offline (harvest-now, decrypt-later attacks, cracking a TLS certificate, etc.). This gives us a little breathing room: downgrade attacks are unlikely to be the first target of cryptographically relevant quantum computers, given there is much, much more low-hanging fruit. On the other hand, there's a non-negligible chance that Q-day will arrive before we've had time to disable classical-only across the IPsec ecosystem. We don't yet know precisely how long it will take to crack a Diffie-Hellman key agreement, but it's a safe bet that the capabilities of quantum computers will ramp up quickly once they arrive. It's best to get ahead of the threat while we're in the midst of other PQ upgrades for IPsec, especially given how long it takes for these upgrades to get deployed across the ecosystem. The simplest way to mitigate this attack is to disable classical-only key agreement (i.e., IKEv2 configurations with an initial Diffie-Hellman exchange but with no PQ key exchange following it). This is easier said than done, however: the reason parameter negotiation exists in TLS and IPsec at all is because the initiator doesn't always know the capabilities of the responder before attempting to connect (and vice versa). In some cases, an [HSTS](https://datatracker.ietf.org/doc/html/rfc6797)-like mechanism is possible. With HSTS (HTTP Strict Transport Security), a client remembers which of its peers and servers have supported PQ in an earlier connection, and then rejects classical-only in all future connections to those peers. This works as long as you know who is trying to connect, i.e., when your peer identifies themselves. But in IKEv2, negotiation happens in the initial exchange; the peer doesn't identify themselves until the authentication exchange, by which time it's too late. In any case, this solution fails to address the fundamental problem. Remember that each endpoint signs its outbound messages only, and doesn't sign the messages sent by its peer. This allows an attacker to create a "split view" of the protocol's execution: the initiator sees one sequence of messages, and the responder sees another. Downgrade attacks wouldn't be possible had the initiator and responder confirmed they had a matching conversation. In modern handshake protocols, like TLS 1.3, each authenticating party signs the entire handshake transcript, including the messages they received from the relying party. This allows the relying party to confirm it had the same conversation, thereby preventing the split view exploited by the downgrade attack. We prefer this more principled approach. We worked with the IPsec Maintenance (IPSECME) Working Group at IETF to develop [an extension for IKEv2](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/) (soon to be an RFC!) called `IKE_SA_INIT_FULL_TRANSCRIPT_AUTH` that endows the protocol with full transcript authentication. For backwards compatibility, use of this extension is negotiated just like any other feature. This means the extension itself is subject to downgrade attack, but the extension uses a clever trick to prevent this. The extension is very simple: The trick that prevents downgrades is unconditional notification. Let's say Mallory modifies the initial exchange by dropping the `IKE_SA_INIT_FULL_TRANSCRIPT_AUTH` notification from the initiator's message, but allows the responder's notification to go through. In this case, the responder falls back to the old authentication logic, but the initiator opts in to the new logic. The responder will end up signing a different byte sequence than the initiator verifies, causing the authentication exchange to fail and resulting in an `AUTHENTICATION_FAILURE` notification. A similar thing happens if Mallory drops the responder's notification but lets the initiator's through. Now consider what happens if Mallory drops the notification from both messages. This would cause both parties to fall back to the old authentication logic, allowing Mallory to downgrade the connection and compute the encryption key. But to pull off the attack, Mallory would need to forge a signature not just from the initiator, but the responder as well. When attempting identity misbinding, Mallory would need to present an identity for a different responder than the initiator wanted to connect to. It's as if the initiator attempted to connect to `example.com`, but got a certificate for `cloudflare.com`. Unless the initiator is severely misconfigured, this will cause the authentication step to fail. If Mallory manages to compromise the credentials of both the initiator and responder, then they can indeed pull off the key compromise impersonation variant of this attack. However, in this case Mallory has much simpler attacks at their disposal. For IKE negotiations, Cloudflare simply acts as a responder. This feature is gated under a feature flag scoped to each customer account. Any customer interested in trying it out can request this flag to be enabled on their behalf by reaching out to their account team. Here’s what happens at the protocol level, for accounts that enable this flag.  The `IKE_SA_INIT_FULL_TRANSCRIPT_AUTH` notification will be sent during the `IKE_SA_INIT` response. We will enable this flag for all customer accounts after sufficient beta testing. The feature gate is created to account for the unlikely scenario that the customer's IKEv2 initiator incorrectly handles the new notification. As of this writing, this feature is on its way to RFC status. Much of the credit goes to our co-author Valery Smyslov, who did much of the heavy lifting of shepherding the document. He also spotted the trick that makes the extension downgrade-resistant. The PQ migration is full of surprises. Ideally these surprises are few and far between. The design flaw in IPsec that allows downgrade attacks has been known for some time, at least [10 years](https://eprint.iacr.org/2016/072) as of this writing. There are perhaps many cryptographic protocols in use today with latent bugs that have renewed relevance in the quantum era. Cloudflare has implemented the full transcript authentication extension and made it available on an opt-in basis. We encourage customers to reach out to their account manager to implement and begin testing the extension, and the rest of the IPsec ecosystem to consider implementing it as the draft continues to advance through the IETF.