On Thu, 20 Aug 2026 at 17:12, Ketan Talaulikar <[email protected]> wrote:
> 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. > The appendix is only implementation guidance, I have added a pointer to it from Section 4. Cheers, -Tiru > > 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]
