[IPsec] Re: [EXT] Re: WG Last Call: draft-ietf-ipsecme-ikev2-mlkem-02 (Ends 2025-09-05)

[Blumenthal, Uri - 0553 - MITLL]

The most commonly used “description” for CRQC that I’ve seen is “Crypto-Relevant Quantum Computer”. Second most-common was Cryptographically-Relevant.  I agree that Cryptanalytically-Relevant works be the most accurate description.  — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory On Sep 8, 2025, at 13:29, Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org> wrote:  Hi Chris, Thank you. I fixed all of these in the -03 which will be submitted later https: //github. com/csosto-pk/pq-mlkem-ikev2/commit/7bbc0c402dc577e4b93716f373a5ddc040f60c6f . Note, I kept the “cryptanalytically relevant quantum computer”, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory.   ZjQcmQRYFpfptBannerEnd Hi Chris,   Thank you.  I fixed all of these in the -03 which will be submitted later https://github.com/csosto-pk/pq-mlkem-ikev2/commit/7bbc0c402dc577e4b93716f373a5ddc040f60c6f . Note, I kept the “cryptanalytically relevant quantum computer”, because it is more accurate although “cryptographically …” is more frequently used.       From: Christopher Patton <cpat...@cloudflare.com> Sent: Wednesday, August 27, 2025 1:37 PM To: Tero Kivinen <kivi...@iki.fi> Cc: draft-ietf-ipsecme-ikev2-ml...@ietf.org; ipsec@ietf.org; ipsecme-cha...@ietf.org Subject: RE: [EXTERNAL] [IPsec] 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.   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 <nore...@ietf.org> 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 ipsec@ietf.org 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 -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org