Thanks, Tiru and Scott. Sorry, I misunderstood Appendix A by just reading it separately. The replies from you two have cleared all my questions below.
Here is one minor suggestion. As the 2nd way (following RFC 8420) discussed in Appendix A is selected in this specification, it may be better to more explicitly reference this way in the last sentence in Appendix A. For example, it may be updated this: “After analysis, the IPSECME working group chose the approach in [RFC8420] as cryptographically most secure way to integrate PQC algorithms into IKEv2.” ==> “After analysis, the IPSECME working group chose the approach in [RFC8420], the 2nd way discussed in the above, as cryptographically most secure way to integrate PQC algorithms into IKEv2. The details are specified in Section 3.21. ” Cheers, Guilin From: tirumal reddy <[email protected]> Sent: Monday, 6 October 2025 1:55 pm To: Wang Guilin <[email protected]> Cc: ipsec <[email protected]>; Wang Guilin <[email protected]> Subject: Re: [IPsec] Re: I-D Action: draft-ietf-ipsecme-ikev2-pqc-auth-04.txt Hi Wang, Please see inline On Mon, 6 Oct 2025 at 09:35, Wang Guilin <[email protected]<mailto:[email protected]>> wrote: 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. Yes, it could be referred to as "double hashing" or "fake prehashing". 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.) The draft exactly says the same, please see the 3rd paragraph in https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-pqc-auth-04.html#section-3.2.1. 3) The above paragraph claims this "is secure". Not sure if a formal security analysis is neccessary to show that it is indeed secure. No, the draft does not say the mechanism in the above paragraph is selected, it is only listed as one possible alternative which was not selected. 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. The Appendix is only listing various possible solutions, no other solution other than the one mentioned in RFC8420 is proposed by the draft. -Tiru 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]<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]
