Hi Scott,
thank you for this review.
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.
Exactly L
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).
Sure, if an attacker compromises both keys, then the game is over. But the
protection of the keys can be very different for initiator and responder,
so it is not unrealistic assumption that for the attacker it could be easier
to compromise client's key, than server's key, which can, say, reside in
HSM.
* 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'm definitely not an expert in QC and I trust you in this observations. My
point is that it is always better to have a protection on the protocol
layer and forget completely about this problem, even if we assume (mostly
probably correctly, but who knows) that the problem is unlikely to become
serious soon (or ever).
* 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.
By no meant this draft should block draft-ietf-ipsecme-ikev2-mlkem.
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).
That is exactly what we propose (but we assume that "low priority"
will hopefully not mean "in a year or two, or decade").
Regards,
Valery.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
