Thank you Scott. ACK, about ML-KEM-512. Ben brought it up as well. Initially I was focusing on ML-KEM-768 and higher for the same reason ML-KEM-512 has not made it to TLS 1.3, extra caution regarding its theoretical security level (<128-bits). I am open to adding ML-KEM-512 which could fit in the IKE_SA_INIT. I think even ML-KEM-768 may fit in a 1400 packet, but I wanted to confirm that in testing. Maybe the better option would be to get an identifier for ML-KEM-512, but for the draft to recommend 768. Regardless, let's discuss this further at IETF-119.
ACK about your other two suggestions about randomness. I think I will add it in the Security Considerations section. I will also add text about KEM key re-use. But I don't think we should allow it for forward secrecy reasons. Why would we let the initiator re-use a KEM public key given that ML-KEM Keygen is relatively fast? From: IPsec <[email protected]> On Behalf Of Scott Fluhrer (sfluhrer) Sent: Friday, January 26, 2024 1:34 PM To: [email protected] Subject: [EXTERNAL] [IPsec] Comments on draft-kampanakis-ml-kem-ikev2 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. 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
