I just went through the draft, and it looks good. However, I do have some comments/questions:
* I see you don't support ML-KEM-512 - is there a specific reason for that? If it is truly level 1 (as strong as AES-128), it should be strong enough for most uses (and for some uses, it'll be important to reduce the compute time/packet sizes). * On the same note, it occurs to me that, if someone doesn't want to use a quantum-nonsafe algorithm, even in the initial exchange, they could do ML-KEM-512 there (which should be short enough not to cause fragmentation, as long as the other payloads are a reasonable size), and then in the IKE_INTERMEDIATE, do a full ML-KEM-768 or ML-KEM-1024. * Should you include any mandates as to whether the initiator can reuse KEM public keys (from a cryptographic perspective, it's fine)? If he is allowed to, should there be any guidance how long they can reuse them (as long as they have the private keys in memory, they don't have PFS for those SAs). Even if you don't mandate anything, I believe it would be good to raise the issue. * Should there be a note that the randomness used to generate the public key (by the initiator) and the ciphertext (by the responder) should be independent of any other keys used? This is self-evident to anyone who knows crypto; however, I can see a clever implementor 'optimizing' the system by using the same seed to generate both the KEM private key and the ECDH private key...
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
