Review of draft-kampanakis-ml-kem-ikev2-02 Hi, I think IPSECME should adopt this draft asap. This should definitely be a standards track RFC.
I really like that IKEv2 register KEMs as separate code points and not hybrid code points like in TLS 1.3. I think the hybrid code points in TLS 1.3 might end up being a mess. It is also a good long-term solution, as long-term, people might want to use only a quantum-resistant KEM such as ML-KEM. We would also like to be able to use ML-DSA for authentication in IKEv2. Is there any draft-xxx-ml-dsa-ikev2, otherwise it should be written asap. I am happy to help. https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/ Comments of the draft: - “Post-quantum” I think the draft should remove “post-quantum” and only use the term “quantum-resistant”, this aligns with draft-ietf-lamps-dilithium-certificates, draft-gazdag-x509-slhdsa, and CNSA 2.0. “Post-quantum” is quite a strange term as ML-KEM needs to be deployed way before CRQCs are built. - “As post-quantum keys are usually larger than common network Maximum Transport Units (MTU)“ “usually” depends on your sample of algorithms and security categories. As the ciphertext is not a key, I think it would be good to talk about encapsulation keys and ciphertexts, which aligns with FIPS 203. The encapsulation keys and ciphertexts in ML-KEM-512 and ML-KEM-768 are smaller than the typical Internet MTU. Also, it is the packet size carrying the encapsulation key or ciphertext that matters, not just the key ciphertext sizes themselves. - “ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed typical network MTUs (1500 bytes). ML-KEM-768 encapsulation keys and ciphertexts are smaller than 1500 bytes. The word "can" is weird as the sizes are fixed. Should probably talk about packets. - “Thus, ML-KEM-1024 Key Exchange Method identifier TBD37 SHOULD only be used in IKE_INTERMEDIATE exchanges. It SHOULD NOT be used in IKE_FOLLOWUP_KE messages until there is a separate document which defines how such exchanges are split in several messages.” I think this should be rewritten to say that ML-KEM-1024 should only be used in IKE_SA_INIT when it is known that the network MTU is large. There is no reason to discourage use of ML-KEM-1024 in networks that use 9000 bytes ethernet jumbo frames. - “which generates a public key 'pk' and a secret key 'sk'.” I think the document should align with FIPS 203, which calls them encapsulation key and decapsulation key. - “Otherwise keep a normative reference of [FIPS203].” I think FIPS203 should be the normative reference no matter what. - " which will not have material performance impact on IKEv2/IPsec tunnels which usually stay up for long periods of time." Not sure that long-lived tunnels are so relevant as best practice is to rekey with PFS based on both time and data (ANSSI says 1 hour or 100 GB). https://cyber.gouv.fr/sites/default/files/2015/09/NT_IPsec_EN.pdf I think the document should stress how fast ML-KEM is. On a single core AMD Ryzen 5 5560U [17], a mobile CPU from 2021, the cryptographic operations in ML-KEM takes 12 μs for the initiator and 8 μs for the responder. The key generation can be pre-computed, reducing the time required for real-time cryptographic operations to 6 μs for the initiator and 8 μs for the responder. https://bench.cr.yp.to/results-kem.html - “Consider adding ML-KEM-512 which would fit in one packet.” I strongly think this document should just register all variant in FIPS 203. NIST latest assessment is that “the most plausible values for the practical security of Kyber512 against known attacks are significantly higher than that of AES128”. Ericsson agrees with that assessment and so do Sophie Schmieg (Google). https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf https://keymaterial.net/2023/11/18/kyber512s-security-level/ - “The ML-KEM-768 public key is 1184 bytes” I think it would be good with a table that shows the encapsulation key and ciphertext sizes for ML-KEM-512, ML-KEM-768, and ML-KEM-1024. - “Although ML-KEM is IND-CCA2 secure, reusing the same ML-KEM keypair does not offer forward secrecy.” I strongly think IPsec should continue to use the term "perfect forward secrecy", this aligns with RFC 4949, RFC 7296 and most government documents talking about ephemeral key exchange in IKEv2. The TLS 1.3 use of "forward secrecy" for both ephemeral key exchange and symmetric ratcheting has had the unfortunate result that people think they get the same security properties from both, which is absolutely not the case. - “The initiator should generate a new ML-KEM keypair with every ML-KEM key exchange.” I think this should be a MUST. On a single core AMD Ryzen 5 5560U [17], a mobile CPU from 2021, key generation with ML-KEM-512 takes the initiator 6 microsecond. Reuse was needed with the very slow FFDH key exchange on old CPUs of the past. Forbidding reuse significantly simplifies the security analysis. Cheers, John Preuß Mattsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
