Hi, I support publication. This is already implemented in several libraries. As Panos writes, this is very straightforward. If there is any disagreement of any text, I would suggest just deleting the text. Much of the text is not required for this simple code point registration. In general, I think less text would have been better.
Comments: - "This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges." I think "with a traditional key exchange" would be better here. - "and theoretical weaknesses in ML-KEM." My view is that the major reason to use a PQ/T hybrid is implementation bugs like side-channels in early implementations. ANSSI that requires hybridization of ML-KEM says that they have the highest confidence in ML-KEM and states that hybridization will likely be optional at some point in the future. - "At the end of Round 3, they picked Kyber as the first Key Encapsulation Mechanism (KEM) for standardization [I-D.draft-cfrg-schwabe-kyber-04]." I see no reason to refer to this expired draft. I would suggest removing the whole sentence as this history is not relevent for this specification. - "ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the typical network MTU" I think this should be "sizes can exceed the network MTU" or "sizes exceed the typical network MTU" - this document focuses on using ML-KEM as the second key exchange in a PQ/T Hybrid KEM [I-D.ietf-pquip-pqt-hybrid-terminology-04] scenario [I-D.ietf-pquip-pqt-hybrid-terminology-04] is now RFC 9794. I would also remove “second”, as that is not discussed elsewhere. ML-KEM could be key exchange 1-8. - "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]." "Initiators SHOULD perform the Ciphertext type check specified in section 7.3 of the Module-Lattice-Based KEM standard [FIPS203] before the Decaps(sk, ct) operation." "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 to violate FIPS 203, which says: "This algorithm requires input checking, as specified below", "ML-KEM.Decaps shall not be run with a decapsulation key or a ciphertext unless both have been checked.". I am against violating FIPS 203. I suggest MUST or just removing the text. - "IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused" This sentence about static keys is not relevant for IKEv2. I suggest removing it. - "Generating an ephemeral key exchange keypair for ECDH and ML-KEM is REQUIRED per connection by this specification, as is common practice for (EC)DH keys today." NIST forbids reuse of ephemeral (EC)DH keys and plan to do the same for ML-KEM. Any IKEv2 implementation reusing the ephemeral (EC)DH keys are not compliant with NIST. The main reason why reuse is and should be forbidden is to make session keys independent of each other. Reuse of ephemeral (EC)DH keys in combination with other implementation bugs has practically led to complete breach of connections. - "mlkem-512", "mlkem-768", and "mlkem-1024" The names are not aligning with the table and the current IANA registrations. - "38-1023 | Unassigned" I don't think this row should be in the document. Cheers, John From: Wang Guilin <[email protected]> Date: Friday, 29 August 2025 at 18:48 To: Kampanakis, Panos <[email protected]>, Tero Kivinen <[email protected]>, draft-ietf-ipsecme-ikev2-mlkem <[email protected]>, ipsec <[email protected]>, ipsecme-chairs <[email protected]> Cc: Wang Guilin <[email protected]> Subject: [IPsec] Re: WG Last Call: draft-ietf-ipsecme-ikev2-mlkem-02 (Ends 2025-09-05) I support adoption. The draft is well prepared. Guilin 发件人：Kampanakis, Panos <[email protected]<mailto:[email protected]>> 收件人：Tero Kivinen <[email protected]<mailto:[email protected]>>;draft-ietf-ipsecme-ikev2-mlkem <[email protected]<mailto:[email protected]>>;ipsec <[email protected]<mailto:[email protected]>>;ipsecme-chairs <[email protected]<mailto:[email protected]>> 时 间：2025-08-23 11:05:18 主 题：[IPsec] Re: WG Last Call: draft-ietf-ipsecme-ikev2-mlkem-02 (Ends 2025-09-05) As an author, I naturally support WGLC. I have addressed comments in the list so far and added a couple of paragraphs about downgrades. It is a straightforward draft that does not introduce any changes other than getting IANA identifiers and summarizing how ML-KEM can be used with rfc9370. Thx -----Original Message----- From: Tero Kivinen via Datatracker <[email protected]> Sent: Friday, August 22, 2025 12:59 PM To: [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] WG Last Call: draft-ietf-ipsecme-ikev2-mlkem-02 (Ends 2025-09-05) 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. Subject: WG Last Call: draft-ietf-ipsecme-ikev2-mlkem-02 (Ends 2025-09-05) This message starts a 2-week WG Last Call for this document. Abstract: NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. File can be retrieved from: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [email protected] in copy. Objections should be motivated and suggestions to resolve them are highly appreciated. Authors, and WG participants in general, are reminded again of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/ _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
