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/ _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
