Hi, Tiru, Nice to see the new version. About the rationale explained in Appendix A, I have a few comments. For easy reference, the following paragraph is copied from Appendix A.
"The third way is what we can refer to as 'fake prehashing'; IKEv2 would generate the hash as specified by the pre-hash modes in [FIPS204] and [FIPS205], but instead of running ML-DSA or SLH-DSA in prehash mode, the hash is signed as if it were the unhashed message, as is done in pure mode. This is a violation of the spirit, if not the letter of FIPS 204, 205. However, it is secure (assuming the hash function is strong), and fits in cleanly with both the existing IKEv2 architecture, and what crypto libraries provide. Additionally, for SLH-DSA, this means that we're now dependent on collision resistance (while the rest of the SLH-DSA architecture was carefully designed not to be)." Here are my comments. 1) The approach used in this version is called 'fake prehashing'. However, according to the description given in the above paragraph, it is acutally 'double hashing', as it does run 'prehashing' and the prehashed result is used by ML-DSA with its internal hash again. 2) As I member, several of us in this mailing list suggested use 'empty hash' or 'identity hash' as the prehash. Namely, it just runs an empty or identity hash to process the input IKEv2 to-be-authenticated message and oupts just the messgae itself (not hashed at all, in fact). Then, the message is input to ML-DSA or SLH-DSA. Not sure why this suggestion is not considered? The IKEv2 specification does not allow to do this? (I once mentioned not sure if there is such limit.) 3) The above paragraph claims this "is secure". Not sure if a formal security analysis is neccessary to show that it is indeed secure. 4) Regulation issue. The above paragraph does acknowledges that "this is a violation of" the specification of FIPS 204 and 205. So, regulation violation or controversial issues will likely be introduced once ML-DSA or SLH-DSA is used this way. Cheers, Guilin 发件人：tirumal reddy <[email protected]<mailto:[email protected]>> 收件人：ipsec <[email protected]<mailto:[email protected]>> 时 间：2025-10-05 16:57:56 主 题：[IPsec] Re: I-D Action: draft-ietf-ipsecme-ikev2-pqc-auth-04.txt The revised draft https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-pqc-auth-04.html adopts the RFC8420 approach; the rationale is explained in Appendix A. The draft appears ready for WGLC. Best Regards, -Tiru On Sun, 5 Oct 2025 at 12:43, <[email protected]<mailto:[email protected]>> wrote: Internet-Draft draft-ietf-ipsecme-ikev2-pqc-auth-04.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC Authors: Tirumaleswar Reddy Valery Smyslov Scott Fluhrer Name: draft-ietf-ipsecme-ikev2-pqc-auth-04.txt Pages: 15 Dates: 2025-10-05 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. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc-auth/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-pqc-auth-04.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-pqc-auth-04 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ 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]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
