Thanks Ketan for the review, raised PR https://github.com/tireddy2/ikev2-pqc -auth/pull/46 to address your comments.
-Tiru On Tue, 18 Aug 2026 at 19:45, Ketan Talaulikar via Datatracker < [email protected]> wrote: > 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]
