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]
