Ketan Talaulikar has entered the following ballot position for draft-ietf-ipsecme-ikev2-pqc-auth-11: No Objection
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-pqc-auth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. Disclaimer: not an IPsec expert and so take my comments might be off; happy to be corrected I have some comments and questions on this document provided inline in the idnits output of v11. Look for the <EoRv11> tag at the end to ensure you are seeing the full review. <major> Section 3.4, IKEv2 Message Fragmentation, and normative RFC 9329 276 IKEv2 peers supporting the PQC authentication mechanism defined in 277 this specification MUST implement IKEv2 message fragmentation 278 [RFC7383], unless IKEv2 runs over a reliable transport (e.g., 279 [RFC9329]) or the underlying network is known to support sufficiently 280 large MTUs without fragmentation issues, since PQC public keys and RFC 9329 defines a condition that excuses implementations from an explicit MUST implement requirement and makes that RFC a borderline a normative reference? If the reference is intended to remain merely illustrative, please consider rephrasing that in a separate sentence. However, I don't know how someone can figure the underlying network without a user provided config/policy knob and I can't say whether or not that makes RFC 9329 more like a given thing that is needed? <major> Are RFCs 9881 and 9909 Normative References? Same Q as Deb raised. 433 The three security levels of ML-DSA are identified via 434 AlgorithmIdentifier ASN.1 objects, as specified in NIST [CSOR] and 435 referenced in PKIX Algorithm Identifiers for the ML-DSA [RFC9881]. 436 [FIPS204] defines both a pure and a pre-hash variant of ML-DSA, but 437 PKIX Algorithm Identifiers for the ML-DSA [RFC9881] specifies only 438 the pure variant. 440 The different parameter sets of SLH-DSA are identified via 441 AlgorithmIdentifier ASN.1 objects, as specified in NIST [CSOR] and 442 referenced in PKIX Algorithm Identifiers for the SLH-DSA [RFC9909]. 483 The Security Considerations section of PKIX Algorithm Identifiers for 484 ML-DSA [RFC9881] and PKIX Algorithm Identifiers for SLH-DSA [RFC9909] 485 apply to this specification as well. I could be wrong, but they seem to depend on and require a reader/implementer to go through those? <major> This is related to Security Considerations. The document explains how peers advertise PQC authentication methods, but it does not state what local policy is necessary when post-quantum authentication is a requirement rather than an opportunistic preference. RFC 9593 Section 6 (https://www.rfc-editor.org/rfc/rfc9593.html#section-6) warns that an attacker able to break one announced authentication method online can strip stronger methods and induce the weaker choice. Is something on those lines required or at least be helpful here? 635 The second approach involves using the Externalμ-ML-DSA API allowed 636 by [FIPS204]; specifically by the comment to line 6 of algorithm 7 of 637 FIPS 204. In this method, the implementation calls the External μ 638 pre-hashing mode with the SignedOctets string and the ML-DSA public 639 key, which externalizes the message pre-hashing originally performed 640 inside the signing operation (see Appendix D of [RFC9881] for ML-DSA 641 pre-hashing). The resulting μ value is then passed to the 642 cryptographic library to execute the Externalμ-ML-DSA.Sign API, which 643 uses μ and the ML-DSA private key to produce the signature. This 644 document specifies only the use of ML-DSA's External μ mode and does 645 not use HashML-DSA. 649 Both approaches are considered "pure" mode and produce the same ML- 650 DSA signature and are fully interoperable. <question> This is about appendix A - it appears to provide implementation guidance? If so, please consider moving the normative/interoperability-relevant text into the relevant sections ? <EoRv11> _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
