On Thu, 9 Oct 2025 at 19:28, Wang Guilin <[email protected]> wrote:
> 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. ” > Thanks, fixed in https://github.com/tireddy2/ikev2-pqc-auth/pull/29 -Tiru > > > 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 <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]
