Hello ipsecme, Regarding draft-kampanakis-ml-kem-ikev2, I am interested to know whether the following instantiation of the draft seems reasonable- it isn't explicitly provisioned for in the draft, but I don't see any issues that would prevent it from working.
In a scenario where a traditional key establishment algorithm is used in IKE_SA_INIT and ML-KEM is used in IKE_INTERMEDIATE, the draft implies (but does not require) that when rekeying or creating a child SA, the traditional algorithm would be used again in CREATE_CHILD_SA, and then ML-KEM would be used in IKE_FOLLOWUP_KE. I am wondering if anything would prevent ML-KEM from being used directly in CREATE_CHILD_SA (in other words, using only ML-KEM to rekey or create a child SA instead of using both the traditional algorithm and ML-KEM, and not using an IKE_FOLLOWUP_KE exchange)? My understanding is that a new SA proposal is sent in CREATE_CHILD_SA (new compared to the SA proposal in IKE_SA_INIT, that is), so it would be okay if ML-KEM is ADDKE1 in SA[i/r]1 but Key Exchange Method in the SA Payloads of CREATE_CHILD_SA. If this seems like a reasonable option, I would support adding text to the draft that more explicitly allows for this as a possibility (and would gladly contribute some text). I'll add that I do not consider this to be an issue that should slow down WG adoption of this draft in any way; I would very much like to see WG adoption happen soon. Thanks, Rebecca Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA)
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
