I went through the draft, and as a protocol change, it looks good - it should be fairly simple to implement, and doesn't appear to have any strong downsides. It is something that IKEv2 should have done from the beginning.
On the other hand, I do have these comments: * 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). * 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. * 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. 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).
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
