Hi Wang, Please see inline
On Mon, 6 Oct 2025 at 09:35, Wang Guilin <Wang.Guilin= [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]> > *收件人：*ipsec <[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]> 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] >> To unsubscribe send an email to [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]
