I would also support adoption. On Sat, 30 Aug 2025 at 08:56, John Mattsson <[email protected]> wrote: > > 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]> > > 收件人：Tero Kivinen <[email protected]>;draft-ietf-ipsecme-ikev2-mlkem > <[email protected]>;ipsec > <[email protected]>;ipsecme-chairs <[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]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
