[IPsec] Re: Mahesh Jethanandani's Discuss on draft-ietf-ipsecme-ikev2-mlkem-07: (with DISCUSS and COMMENT)

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

Hi Mahesh, 

I addressed them. I rephrased to 

If the checks fail, the responder MUST reject the initiator's
improper public key and SHOULD send a Notify payload of type INVALID_SYNTAX
as a response to the request to prevent resource exhaustion or denial 
of service risks.

> Section 2.2, opening sentence:
229 >    Receiving and handling of malformed ML-KEM public keys or ciphertexts
230 >    must follow the input validation described in the Module-Lattice-
231 >    Based KEM standard [FIPS203].
> Why a "must" and not a "MUST"? This sentence sets the scope for the Recipient Tests section and appears intended to be normative. It should use "MUST".

We have a generic must initially, but the normative language later has "MUST" for specific test. The intro sentence talks about the general idea. 

I fixed all the nits as well. 

Thank you


-----Original Message-----
From: Mahesh Jethanandani via Datatracker <[e-mail]> 
Sent: Friday, June 26, 2026 7:51 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [EXTERNAL] Mahesh Jethanandani's Discuss on draft-ietf-ipsecme-ikev2-mlkem-07: (with DISCUSS and COMMENT)

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.



Mahesh Jethanandani has entered the following ballot position for
draft-ietf-ipsecme-ikev2-mlkem-07: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have, but one DISCUSS that I think should be simple to fix.

Section 2.2, Recipient Tests:

229 >    Receiving and handling of malformed ML-KEM public keys or ciphertexts
230 >    must follow the input validation described in the Module-Lattice-
231 >    Based KEM standard [FIPS203].  Responders MUST perform the checks on
232 >    the initiator public key specified in section 7.2 of the Module-
233 >    Lattice-Based KEM standard [FIPS203] before the Encaps(pk) operation.
234 >    If the checks fail, the responder SHOULD reject the initiator's
235 >    improper public key and send a Notify payload of type INVALID_SYNTAX
236 >    as a response to the request to prevent resource exhaustion or denial
237 >    of service risks.

Why a SHOULD and not a MUST?

The first sentence mandates (MUST) that the responder perform the Section 7.2 FIPS 203 key type checks before calling Encaps(pk). Once those checks have failed, there are only two viable paths: (a) reject the key and signal an error, or (b) call Encaps(pk) anyway. Path (b) violates FIPS 203 — Encaps(pk) is not defined for a key that fails the Section 7.2 type checks — so path (a) is the only conformant behavior.
Using SHOULD for path (a) leaves open path (b) without describing the "valid reasons in particular circumstances" that RFC 2119 requires when SHOULD is used. The document itself gives the reason for rejecting (prevent resource exhaustion and DoS) but gives no reason for not rejecting in the first place, making the SHOULD unanchored.

The asymmetry with the initiator's ciphertext check heightens my concern. The initiator case (lines 241–247) uses MUST throughout: "the initiator MUST reject the ciphertext and MUST fail the exchange." Both parties are validating untrusted input before a cryptographic operation; the normative level should be parallel/similar. The responder's SHOULD should be MUST.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.2, opening sentence:

229 >    Receiving and handling of malformed ML-KEM public keys or ciphertexts
230 >    must follow the input validation described in the Module-Lattice-
231 >    Based KEM standard [FIPS203].

Why a "must" and not a "MUST"? This sentence sets the scope for the Recipient Tests section and appears intended to be normative. It should use "MUST".

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool) so there will likely be some false positives. There is no need to let me know what you did with these suggestions.

Section 2.1:

210 >    Although, this document focuses on using ML-KEM as the second key

s/Although,/Although/

Section 3, last paragraph (sentence missing terminal period):

345 >    (including traffic selectors), but not the information and data
346 >    encrypted after the CREATE_CHILD_SA (and IKE_FOLLOWUP_KE with ML-
347 >    KEM)

Add a period after "KEM)".

Appendix A:

531 >    ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts, specufically,

s/specufically/specifically/