I believe this document is ready to publish, modulo the following minor comments:
* Section 2.3: This section says the peers SHOULD do input validation on the KEM public key and ciphertexts. Is there a circumstance where it's safe for an implementation to forego these checks? Should this be a MUST instead? * Section 3: "... although the keys could be reused if the nonces are never reused.": I think you mean that the key exchange could be replayed as long as fresh nonces are used. If so, it's not clear for what security property this is true. (In any case, you would lose forward secrecy if you reuse the key exchange.) I would just cut this, as it doesn't add much. Nits: * Intro: "cryptanalytically relevant quantum computer": I think "cryptographically relevant quantum computer" is more commonly used. * Section 1.1: I notice the KEM syntax is annotated with single quotes here (e.g., 'ct'), but not elsewhere in the document. * Section 2.1: The KEM key pair is written as (sk, pk), but is written as (pk, sk) in Section 1.1.' * Section 2.2: In the payload diagram, I was wondering if the dividers between the first two rows should be aligned? * Section 3: It might be useful to add an informative reference for IND-CCA2. I think pointing to FIPS203 would be fine. * Section 3: "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." I initially read this as saying that "hybrid is REQUIRED by this specification". Suggested reword: "Generating an ephemeral public key and ciphertext for each ML-KEM exchanged is REQUIRED by this specification. Note that this is also common practice for (EC)DH keys today." Best, Chris P. On Fri, Aug 22, 2025 at 9:59 AM Tero Kivinen via Datatracker < [email protected]> wrote: > > 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]
