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

["Kampanakis, Panos" <[e-mail]>]

Hi John,
Thank you for the feedback. These were addressed in https://github.com/csosto-pk/pq-mlkem-ikev2/commit/fa5dd8bd441c9f277bdc232c6eb4abe4b78762a0 The normative MUSTs regarding ephemeral exchanges were updated in a previous fix.


From: John Mattsson <[e-mail]>
Sent: Saturday, August 30, 2025 12:56 AM
To: Wang Guilin <Wang.Guilin=[e-mail]>; Kampanakis, Panos <kpanos=[e-mail]>; Tero Kivinen <[e-mail]>; draft-ietf-ipsecme-ikev2-mlkem <[e-mail]>; ipsec <[e-mail]>; ipsecme-chairs <[e-mail]>
Cc: Wang Guilin <[e-mail]>
Subject: RE: [EXTERNAL] [IPsec] Re: 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.

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 <Wang.Guilin=[e-mail]<mailto:Wang.Guilin=[e-mail]>>
Date: Friday, 29 August 2025 at 18:48
To: Kampanakis, Panos <kpanos=[e-mail]<mailto:kpanos=[e-mail]>>, Tero Kivinen <[e-mail]<mailto:[e-mail]>>, draft-ietf-ipsecme-ikev2-mlkem <[e-mail]<mailto:[e-mail]>>, ipsec <[e-mail]<mailto:[e-mail]>>, ipsecme-chairs <[e-mail]<mailto:[e-mail]>>
Cc: Wang Guilin <[e-mail]<mailto:[e-mail]>>
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 <kpanos=[e-mail]<mailto:kpanos=[e-mail]>>
收件人：Tero Kivinen <[e-mail]<mailto:[e-mail]>>;draft-ietf-ipsecme-ikev2-mlkem <[e-mail]<mailto:[e-mail]>>;ipsec <[e-mail]<mailto:[e-mail]>>;ipsecme-chairs <[e-mail]<mailto:[e-mail]>>
时 间：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 <[e-mail]<mailto:[e-mail]>>
Sent: Friday, August 22, 2025 12:59 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 [e-mail]<mailto:[e-mail]> 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>