Hi, I am not happy with that formulation. SP 800-227 is not guidance, it defines requirements. My understanding is that Sections 3, 4, and C of SP 800-227 contain requirements (“shall” and “must”) that apply to conforming implementations of ML-KEM in applications. Section 1.3 is just a nice summary.
The only reason not to state explicitly that the requirements in SP 800-227 SHALL be followed would be if there are implementations intending to violate some of NIST’s requirements. I am against the IETF publishing any standards that violate NIST’s requirements for ML-KEM. I am very tired of seeing implementations claiming to support AES-CBC, AES-GCM, RSA, or ML-KEM, while not actually conforming to any official standard. It makes security analysis of systems a real pain. If you use the name ML-KEM, you should follow NIST’s requirements. If this draft intends to deviate from any NIST requirements, it must clearly specify which requirements are not being followed and why. For example: “NIST requires that implementations of ML-KEM ..., but this document does not follow this requirement because ...” Cheers, John From: Kampanakis, Panos <[email protected]> Date: Wednesday, 8 October 2025 at 18:15 To: John Mattsson <[email protected]>, Tero Kivinen <[email protected]>, [email protected] <[email protected]> Subject: RE: [IPsec] Re: WGLC of draft-ietf-ipsecme-ikev2-mlkem is done Hi John, Section 1.3 talks about testable and non-testable CMVP / NIST requirements. Not everyone needs to follow all of those. And not all of them are applicable to IKEv2. I am planning to make the sentence more accurate by rephrasing it to > Refer to Sections 3 and 4 of [SP800227] for guidelines to implement and use > KEMs securely in applications. This sentence informs the reader that they can go read guidance on how to implement and use ML-KEM securely in the IKEv2 implementation. Otherwise, the draft already has normative language about ephemeral keys, proper ML-KEM input checks etc already which should suffice. Mandating “ML-KEM side-channel resistance” in IKEv2 does not help an implementer. If there is specific normative practical guidance for ML-KEM that we are missing, happy to add it. I find that referencing a 56 page document and normatively saying “go comply with all of that” is impractical. If the rest of the WG thinks the doc should have that normative statement, I will add it. From: John Mattsson <[email protected]> Sent: Wednesday, October 8, 2025 1:45 AM To: Tero Kivinen <[email protected]>; [email protected] Subject: [EXTERNAL] [IPsec] Re: WGLC of draft-ietf-ipsecme-ikev2-mlkem is done 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. > Section 4 of [SP800227] includes guidelines for using KEMs securely in > applications. This is not a correct description of SP 800-227. SP 800-227 makes _requirements_ for implementing and using KEMs. The important section is 1.3, which states that "Conforming implementations of approved KEMs are required to satisfy all of the requirements below." FIPS 203 already references SP 800-227, stating: "For general definitions and properties of KEMs, including requirements for the secure use of KEMs in applications, see SP 800-227". IKEv2 is one such application. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf The draft should state that the requirements in SP 800-227 shall be followed. I don't think anyone wants standards or implementations violating NIST requirements, and FIPS 203 and SP 800-227 should be viewed together. Suggestion: NEW: Section 1.3 of [SP800227] includes requirements for using KEMs securely in applications and SHALL be followed. Cheers, John On 2025-10-05, 19:33, "Tero Kivinen" <[email protected]<mailto:[email protected]>> wrote: The WGLC of the draft-ietf-ipsecme-ikev2-mlkem document has finished, and there has been new document published that should resolve all WGLC comments. If there are any comments that were not resolved please send email to the list ASAP. -- [email protected]<mailto:[email protected]>
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
