Hi Scott,
Closing the loop. I added two notes about forward secrecy and randomness independency in the just submitted the -02 version. https://datatracker.ietf.org/doc/html/draft-kampanakis-ml-kem-ikev2-02 I also added EDNOTEs about adding ML-KEM-512 in the future if the WG converges that direction. Thank you for the review and suggestions. Hopefully IPSECME will discuss this draft in Brisbane. From: Scott Fluhrer (sfluhrer) <[email protected]> Sent: Monday, January 29, 2024 2:02 PM To: Kampanakis, Panos <[email protected]>; [email protected] Subject: RE: [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. That's fine; I wasn't advocating whether reusing the public key should be a MAY/SHOULD NOT/MUST NOT, only that the RFC should make an explicit statement about it. Saying that it's in the MUST NOT category is fine... From: Kampanakis, Panos <[email protected]<mailto:[email protected]>> Sent: Monday, January 29, 2024 12:08 PM To: Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: [IPsec] Comments on draft-kampanakis-ml-kem-ikev2 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?
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
