+1 on the new draft not blocking draft-ietf-ipsecme-ikev2-mlkem. I now mention draft-smyslov-ipsecme-ikev2-downgrade-prevention informatively in draft-ietf-ipsecme-ikev2-mlkem as a long term solution and bring up the downgrade and its practical applicability. And mention a workaround of creating a Child SA only after an ML-KEM Followup-KE.
Scott, I could use a review of the new text. It is here https://mailarchive.ietf.org/arch/msg/ipsec/qhbfyW0cE3uv9gXBF4RIVW6OXq0/ From: Christopher Patton <[email protected]> Sent: Tuesday, July 29, 2025 5:22 PM To: Scott Fluhrer (sfluhrer) <[email protected]> Cc: ipsec <[email protected]> Subject: [EXTERNAL] [IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Scott, thanks so much for your review! Comments inline. * I am underwhelmed by the attack this prevents. It assumes that the system is already broken (the attacker has the authentication key of one side, which means that they could masquerade as that party already), and so you really didn't have security in the first place - this attack only arguably makes it worse. And, if we make the further assumption that the attacker has the authentication key on both sides (if he can compromise one, why not both), then a MITM attack is trivial (and doesn't make any 'weak DH' assumptions). I'd like to clarify two things here. First, there is a stronger variant not described in -00 that doesn't require compromising either of the victim peers. This attack is described in the original thread [1] and we have also added a description of the draft [2]. To mount the attack, rather than compromise the victim initiator, the attacker can be any initiator that the victim responder is configured to speak to. The key observation is that the downgrade happens before the initiator identifies itself to the peer. This means the attacker can simply authenticate itself with its own signing key. We refer to this as an "identity misbinding" attack in the draft. Second, the attack as described in -00 is a kind of "key-compromise impersonation" (KCI) attack. (Thanks to Thom Wiggers for knowing the proper terminology!) I totally agree that, in a strong enough threat model, KCI attacks are kind of meaningless. Namely, if an attacker has persistent access to one of the peers, it would use that access to circumvent the cryptography altogether. Where I think KCI makes sense is in a weaker threat model where the attacker only has temporary access. Obviously, it would use that access to steal a key: on the one hand, this would allow it to impersonate one peer to the other; on the other hand, the KCI attack would allow it to eavesdrop on the traffic between the victim peers. It seems to me that the latter has value to the attacker beyond what it gets from impersonation alone. * It further assumes that the attacker could break the 'weak DH' in real time (and first generation CRQCs are quite unlikely to be that fast; second or third generation, maybe, but that's likely several years after q-day). I would hope (possibly a misguided hope, but still) that several years after q-day, people would shut off the 'classical-only' proposals. I completely agree here. I would only add that, from my perspective, the long tail of the internet is still very long, and it doesn't seem to be getting shorter. At least for the web, I would expect to observe classical-only TLS clients well after q-day. Hopefully IPsec deployments will be able to upgrade faster. * It would appear to me that draft-ietf-ipsecme-ikev2-mlkem is being blocked because of this. If my perception is correct, I don't see the reason behind this; this attack would be possible without any PQ algorithm at all (e.g. The policy states that group 19 is preferred, but group 1 is allowed), and there is nothing that draft-ietf-ipsecme-ikev2-mlkem could do to address this attack in the first place. It's not our intent to block progress on draft-ietf-ipsecme-ikev2-mlkem or any other draft that adds PQ key exchange. In my opinion, these drafts should mention the attack and say it can be mitigated by disabling classical-only proposals. I suppose they could also informatively reference draft-smyslov-ipsecme-ikev2-downgrade-prevention, but I wouldn't want them to do so if that meant delaying publication. I would suggest that we advance draft-ietf-ipsecme-ikev2-mlkem (because that adds real security) and possibly deal with draft-smyslov-ipsecme-ikev2-downgrade-prevention as a low priority (but possible) update to IKEv2 (because that covers an odd, but nonempty corner case). Can you clarify what you mean by "update" to IKEv2? During IETF 123 there were suggestions in the chat that this feature could be considered as part of a major revision of IKE. I would prefer we land this in IKE v2 so that we can implement it as soon as possible. The alternative is to disable classical-only key exchange on a per-peer basis, based on out-of-band information about the peer. Thinking about my organization's deployment of IPsec, we're expecting the downgrade prevention extension to be a much smoother upgrade path. Best, Chris P. [1] https://mailarchive.ietf.org/arch/msg/ipsec/vSjVbzw0vAbHIxHvzNLvl3Z-NqU/ [2] https://github.com/smyslov/ikev2-downgrade-prevention/pull/1
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
