Thank you for your comments. See inline (SRF) ________________________________ From: Wang Guilin <[email protected]> Sent: Monday, October 6, 2025 12:04 AM To: tirumal reddy <[email protected]> Cc: ipsec <[email protected]>; Wang Guilin <[email protected]> Subject: [IPsec] Re: I-D Action: draft-ietf-ipsecme-ikev2-pqc-auth-04.txt
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. SRF: That is not the approach used in this version (or, at least, what not we intended to specify) - perhaps you are remembering a previous version where that section did in fact specify that (even though other parts of the draft specified something different). The current version of the draft specifies the "RFC 8420" method, where the IKEv2 implementation doesn't do any hashing at all, but instead hands it to the ML-DSA implementation (which will do its own SHAKE or SHA-2 hashing during signature generation/verification). We can see the RFC 8420 method specified in section 3.2.1 and appendix A (last paragraph). For the record, this method is: * Have IKE "negotiate" a "signature hash algorithm", that is, the hash function that it applies the signed octets to, to be the "identity" function, which just returns the input. * Have IKE pass the output of the identity function (which is the original signed octets string) to the signature algorithm (ML-DSA or SLH-DSA), which will perform its own hash function (SHAKE or SHA-2) 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.) SRF: Actually , that is exactly what the draft specifies, see 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. Well, the identity function trivially meets the "collision resistance" property that we assume (and that's all we need from the IKE hash function); everything else in IKE is either unchanged, or replacing one signature operation with another. 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. SRF: The above paragraph describes a design option we decided not to select. The appendix is there to document the various design options that were available to us when we designed this protocol - I expect we'll delete that appendix when it comes time to convert it into an RFC (because having an RFC talk about design options we decided not to go with may be confusing to an implementor, and ultimately, that's the intended audience for an RFC). 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]
