Hi Panos, Regardless, it is a valid point. I think it is out of scope to address this > in the draft as I consider it a general IKEv2 issue which the WG can tackle > in separate work. >
I agree the problem is not specific to draft-ietf-ipsecme-ikev2-mlkem and that the ideal solution is more general. However, speaking as a potential implementer, I believe the solution ought to be a prerequisite for this draft. The reason is that I think there are extenuating circumstances: The transition to PQ key exchange is well underway in most of the IETF and beyond, and I'm worried that the lack of downgrade resilience will hinder progress for IPSec. In particular, if a draft were created that extended IKEv2 to have stronger downgrade resilience, then I think draft-ietf-ipsecme-ikev2-mlkem ought to depend on it. Such an extension might look like this: The initiator's IKE_INIT_SA message indicates support for an extension wherein, when selected by the responder, each host signs/MAC all key exchange messages, including those sent by its peer. (This seems like it would be necessary for downgrade resilience, though perhaps not sufficient.) We would then make negotiation of ML-KEM in an intermediate exchange contingent on selection of this downgrade resilience extension. Or perhaps we could specify something broader? Of course, unless marked as mandatory by the initiator, this extension is itself vulnerable to downgrade attack. This means there would still be a transition period where most responders don't yet support the extension and thus some initiators would leave it as optional for a period of time. However the time horizon for this transition is the same as for the transition to mandatory-ML-KEM, so I don't think adding it as a dependency costs us any time. The upside is that we provide downgrade resilience for the broader ecosystem. > It is a great idea to add a discussion in the Sec Considerations section. > I will do that. Please review the text when it is out. > I'd be happy to! On the specifics, I agree that saying that the responder can choose to go > ML-KEM-as-mandatory won’t always be possible in the migration phase. > RFC8784 addressed this downgrade scenario by introducing a “peer > PPK_ID-based mandatory_or_not PQ PPK flag” configuration. That way, the > initiator or responder know if it is mandatory to use the PPK with the > PPK_ID for quantum resistance. draft-ietf-ipsecme-ikev2-mlkem does not > negotiate a separate identifier which the peers can use to know if ML-KEM > is mandatory. So, I think the most elegant approach is for those worried > about such downgrades, to force a new Child SA creation or rekey or IKE SA > rekey by using a IKE_FOLLOWUP_KE and make use of a mandatory-ML-KEM-peer > configuration. IKE_FOLLOWUP_KE has authenticated peers and thus the > responder can enforce a “mandatory to use ML-KEM for that peer” > configuration. Wildcard scenarios could be used for such identities to > prevent large config. > > > Thoughts on this solution are welcome. > IKE_FOLLOWUP_KE is defined in RFC 9370 (Multiple Exchanges), correct? How are the peers authenticated in these messages? The attacker knows all session keys at this point, so I imagine they would need something like another AUTH exchange. Best, Chris P.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
