Hi Daniel, The draft was initially specific to ML-DSA and SLH-DSA, but it was updated at the time of WG adoption to make the mechanism generic. The rationale is that future PQC signature algorithms standardized by NIST or other bodies can reuse this mechanism directly, without requiring a new specification unless such algorithms deviate from the generic integration model defined in this draft. Given this prior WG consensus and the goal of long-term reusability, we would not make any changes to the draft.
Also, thank you for your understanding and for not holding up WGLC over these concerns. Cheers, -Tiru On Wed, 22 Oct 2025 at 05:52, Daniel Van Geest <daniel.vangeest= [email protected]> wrote: > Hi, > > Technically, everything is fine. The right things are specified so that > ML-DSA and SLH-DSA can be used in IKEv2. > > But I'm confused about why this draft needs to claim that it "specifies a > generic mechanism for integrating post-quantum cryptographic (PQC) digital > signature algorithms into the IKEv2 protocol" and that it "enables the use > of any PQC digital signature algorithm without modifying core IKEv2 > operations". > > The generality seems unnecessary. The important thing in this document is > that it specifies the use of ML-DSA and SLH-DSA for IKEv2. We don't know > for sure what future PQC signature algorithms will look like, and frankly > even if they were exactly like ML-DSA and SLH-DSA, we wouldn't need a > generic mechanism for integrating them, because future drafts for those > algorithms would still end up specifying the same information, namely: > - use the "Digital Signature" authentication method with these particular > OIDs > - hedged vs deterministic signing doesn't affect interoperability > - set the context parameter to the empty string > - use the "pure" mode of the algorithm. > > The "PQC" TLA appears 56 times in the draft, and while "PQC" is nice and > short, most of the times it is used it could equally say "ML-DSA and > SLH-DSA" or "the algorithms in this draft" or something else that doesn't > imply that this draft should cover future unknown PQC algorithms as well. > > I wouldn't personally try to hold up WGLC over these concerns, I just > think that it would be a cleaner and clearer document if it just stuck to > the ML-DSA and SLH-DSA in IKEv2 specifics and didn't try to claim to be > generic. > > Daniel > > > On 2025-10-08 8:44 a.m., Tero Kivinen via Datatracker wrote: > > Subject: WG Last Call: draft-ietf-ipsecme-ikev2-pqc-auth-04 (Ends 2025-10-22) > > This message starts a 2-week WG Last Call for this document. > > Abstract: > Signature-based authentication methods are utilized in IKEv2 > [RFC7296]. The current version of the Internet Key Exchange Version > 2 (IKEv2) protocol supports traditional digital signatures. > > This document specifies a generic mechanism for integrating post- > quantum cryptographic (PQC) digital signature algorithms into the > IKEv2 protocol. The approach allows for seamless inclusion of any > PQC signature scheme within the existing authentication framework of > IKEv2. Additionally, it outlines how Module-Lattice-Based Digital > Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- > DSA), can be employed as authentication methods within the IKEv2 > protocol, as they have been standardized by NIST. > > File can be retrieved > from:https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc-auth/ > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping [email protected] > in copy. Objections should be motivated and suggestions to resolve them are > highly appreciated. > > Authors, and WG participants in general, are reminded again of the > Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 > [1]. Appropriate IPR disclosures required for full conformance with the > provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of > any. Sanctions available for application to violators of IETF IPR Policy can > be found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
