I have only terminology gripes :-) But, naming the problem properly results in better solutions.
Kampanakis, Panos <[email protected]> wrote: > I like your text """ IKE v2 is susceptible to downgrade attacks > [IKEv2-DOWNGRADE] in which the peers are forced to negotiate the > weakest key exchange method supported by both. In particular, if both > peers support some sequence of key exchanges that involve only > classical algorithms, an active, on-path attacker with a CRQC may be > able to convince the peers to use it even if they both support ML-KEM. I understand calling this a downgrade attack, but I think it deserves a more specific name. Given existence of a CRQC, then it's effectively the same as at least one end point revealing their private key. And, in both situations, the "breach" can occur without either peer knowing. So ignore quantum-safety completely, if one had a policy that permitted quantum-unsafe algorithms, and a key of that kind was compromised, then the situation would be identical, right? (If *I* was a nation-state with a CRQC, I'd keep that point well hidden, even publish papers about the numerous failures my scientists have experienced trying to build one...) > The simplest way to mitigate these attacks is to disable support for > classical-only sequences of key exchanges whenever possible. If the I would not call this a "mitigation" either. It's that the wronly was used. Pick the right policy. Why is this even an issue is because we expect to have permissive policies to allow a flag-day-free transition from (only) quantum-unsafe algorithms to hybrid algorithms. We can't mandate hybrid algorithms until all the users upgrade, and that's gonna take months to small-number-of-years because of maintenance and upgrade patterns in large groups of users. The situation here is that the quantum-unsafe algorithms were not turned off. I suggest that a sensible thing for a remove-access gateway to do is to latch the users. Allow quantum-unsafe only algorithms until the user first uses a hybrid algorithm, and then latch to require that for those credentials. (This could be a problem if the user has multiple devices that share the same credentials, or if the user has to back-out of the newest VPN client for some reason, but that's why you don't upgrade every user overnight) For site-to-site VPNs, the latch might work, but there could also be other subtle problems if one end initiates when it hasn't before, and the latch isn't done quite right. Maybe this is worth a BCP, but I don't think it has protocol implications. If it's all SDN managed/Orchestrated, then update policy,period. If it's PKI based, then maybe a clue that the endpoints are hybrid capable would be that the certificate presented would be hybrid. There is an order of operations consideration here. Maybe one wants to move to a hybrid/composite PKI before a hybrid IKEv2. Maybe it's worth standarizing an OID that says, "IKEv2 should be hybrid" If it's PSK based site-to-site, then a CRQC would not have compromised the quantum-unsafe (RSA,ExDSA) credential, since there isn't one. And we did something to get the IKEv1-quantum-safety from PSKs, right. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
