Thanks Guilin for the review. please see inline On Thu, 9 Oct 2025 at 20:13, Wang Guilin <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? > The document itself does not register any algorithms, it leverages RFC7427 to enable the use of any PQC signature algorithm identified by an OID. > > 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. It has backward compatibility as it does not change the IKEv2 wire protocol. > > > 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. The size of PQC end-entity and intermediate certificates depends on the sizes of 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. Good point, updated text, see https://github.com/tireddy2/ikev2-pqc-auth/pull/30 Cheers, -Tiru > > ================== > > Cheers, > > Guilin > > -----Original Message----- > From: Tero Kivinen via Datatracker <[email protected]> > Sent: Wednesday, 8 October 2025 3:45 pm > To: [email protected]; [email protected]; > [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] 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]
