>Wang Guilin wrote >1) 12 parameter sets for SLH-DSA are introduced in Section 5. It is a lot. >Possible to reduce them?
The intention of RFC 7427 is to enable use of any signature algorithm with an OID. The document does not register any algorithms; it explains which RFCs and external documents you need to use to make this work in an interoperable way. I think the document is perfect as is. Any reduction should be in an RFC8247bis. > not "SUF-CMA" yet. Widely believed to be SUF-CMA for good reasons but not proven to be SUF-CMA yet. I don’t think SLH-DSA should be listed as EUF-CMA, that makes people believe there are attacks on the SUF-CMA security. While EUF-CMA or SUF-CMA matter in LAMPS where you have no idea what the end-entity public key will be used for, I do not think it matters in IKEv2 as ”In the context of signature-based authentication in IKEv2, the data used for generating a digital signature is unique for each session, as it includes session-specific information such as nonces” If the draft talks about SUF-CMA and EUF-CMA, I think this should be explained. Cheers, John On 2025-10-09, 16:34, "Wang Guilin" <[email protected]> wrote: I support! Tried to give a short review below. ================== The current document is well prepared. Here are a few comments. 1) 12 parameter sets for SLH-DSA are introduced in Section 5. It is a lot. Possible to reduce them? 2) Section 1 mentioned "backward compatibility". In which sense for "backward compatibility"? For my understanding, once one entity uses PQ signatures for IKEv2 authentication, if the other just supports traditional signature algorithms, they cannot run this algorithm. 3) Section 3.2.1: " ...., or the underlying network is known to support sufficiently large MTUs without fragmentation issues, since PQC public keys and signatures can be significantly larger than those used in traditional algorithms." Here (IKEv2) is actually about the size of PQC certificates (certificate chains) and signatures, not PQC public keys and signatures. 4) Section 8 (Security Considerations) "PQC signature algorithms are modeled under strong unforgeability against an adaptive chosen message attack (SUF-CMA). Examples include ML-DSA and SLH-DSA, which adhere to this security mode. " According to discussions in the past several days, SLH-DSA is actually "likely SUF-CMA", not "SUF-CMA" yet. Also, not sure if it is more helpful to add one sentence here for telling potential differene when using EUF-CMA and SUF-CMA signatures. ================== Cheers, Guilin -----Original Message----- From: Tero Kivinen via Datatracker <[email protected]<mailto:[email protected]>> Sent: Wednesday, 8 October 2025 3:45 pm To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-pqc-auth-04 (Ends 2025-10-22) 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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
