Hi Panos, Thanks for the quick answer! That addresses my worries.
Two more comments: 1. NIST has just published SP 800-227 (Recommendations for Key-Encapsulation Mechanisms). I think the draft should reference SP 800-227 and state that all the requirements in SP 800-227 MUST be followed. I don’t think anyone wants implementations that violate NIST requirements. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf 2. "ML-KEM-512 and ML-KEM-768 Key Exchange Method identifiers TBD35 and TBD36 respectively MAY be used in IKE_SA_INIT as a quantum-resistant-only key exchange." "ML-KEM-1024 Key Exchange Method identifier TBD37 SHOULD NOT be used in IKE_SA_INIT messages which could exceed typical network MTUs and cannot be IKEv2 fragmented." While this hold true for many networks, jumbo frames are widely supported in internal datacenter networks and IKE_SA_INIT can be transported over TCP. For these types of deployments, I do not think ML-KEM-1024 in IKE_SA_INIT should be discouraged. I suggest something like: "Implementations transporting IKE over UDP and not performing Path MTU (PMTU) discovery SHOULD NOT use ML-KEM-1024 in the IKE_SA_INIT exchange on networks where the PMTU is unknown or restricted. However, when IKE is transported over TCP and on networks where a sufficient PMTU is guaranteed, implementations MAY use ML-KEM-1024 in the IKE_SA_INIT." Cheers, John From: Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org> Date: Saturday, 20 September 2025 at 06:12 To: John Mattsson <john.matts...@ericsson.com>, ipsec <ipsec@ietf.org> Subject: RE: [IPsec] draft-ietf-ipsecme-ikev2-mlkem-02 seems to violate FIPS 203 This was in the feedback I got previously and version 3 https://github.com/csosto-pk/pq-mlkem-ikev2/blob/main/draft-ietf-ipsecme-ikev2-mlkem-03.xml addresses it by using “MUST’ normative language. ~~~ Responders MUST perform the checks on the initiator public key specified in section 7.2 of the Module-Lattice-Based KEM standard [FIPS203] before the Encaps(pk) operation. If the checks fail, the responder SHOULD send a Notify payload of type INVALID_SYNTAX as a response to the request from initiator. Initiators MUST perform the Ciphertext type check specified in section 7.3 of the Module-Lattice-Based KEM standard [FIPS203] before the Decaps(sk, ct) operation. If the check fails, the initiator MUST reject the ciphertext and MUST fail the exchange, log the error, and stop creating the SA (i.e. not initiate IKE_AUTH or next IKE_INTERMEDIATE). If the error occurs in the CREATE_CHILD_SA or IKE_FOLLOWUP_KE exchanges, the initiator MUST delete the existing IKE SA and send a Delete payload in a new INFORMATIONAL exchange for the responder to also remove it. ~~~ From: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Sent: Friday, September 19, 2025 11:43 PM To: ipsec <ipsec@ietf.org> Subject: [EXTERNAL] [IPsec] draft-ietf-ipsecme-ikev2-mlkem-02 seems to violate FIPS 203 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. Hi, 2.3. Recipient Tests states that: "Receiving and handling of malformed ML-KEM public keys or ciphertexts SHOULD follow the input validation described in the Module-Lattice-Based KEM standard [FIPS203]." "Receiving and handling of malformed ML-KEM public keys or ciphertexts SHOULD follow the input validation described in the Module-Lattice-Based KEM standard [FIPS203]." "Responders SHOULD perform the checks specified in section 7.2 of the Module-Lattice-Based KEM standard [FIPS203] before the Encaps(pk) operation." This seems like a violation of FIPS 203 which states that: "ML-KEM.Encaps shall not be run with an encapsulation key that has not been checked as above" "ML-KEM.Decaps shall not be run with a decapsulation key or a ciphertext unless both have been checked." "Ciphertext checking shall be performed with every execution of ML-KEM.Decaps" It does not matter if skipping these tests is secure or not, it you skip any mandatory parts of FIPS 203 it is no longer ML-KEM. ML-KEM-1024 is around 500 times faster than MODP 4096, it does not need further optimizations. I suggest draft-ietf-ipsecme-ikev2-mlkem-02 is changed to state that all requirements in FIPS 203 SHALL be followed. I am against IETF publishing anything claiming to be ML-KEM but then violating FIPS 203. Cheers, John
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
