Hi Tiru, Thanks for the updates. They look good to me except for the one about the appendix. However, since I am not an expert in this area, I defer judgment to Deb and Eric.
Thanks, Ketan On Thu, Aug 20, 2026 at 2:31 PM tirumal reddy <[email protected]> wrote: > 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]
