+1 on keeping one way of doing it without digesting of the message with RFC8420 as stated in section 3.2.1.
I suggest making section 7 an Appendix section that summarizes the options considered and updating to say that the WG chose [RFC8420] because it is the cleanest way and cryptographically most secure (no theoretical hash preimages). From: Scott Fluhrer (sfluhrer) <[email protected]> Sent: Tuesday, September 23, 2025 9:08 AM To: Valery Smyslov <[email protected]>; 'ipsec' <[email protected]> Subject: [EXTERNAL] [IPsec] Re: draft-ietf-ipsecme-ikev2-pqc-auth CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. I see that now - the draft states two different methods at different places (section 3.2.1 vs section 7). Obviously, that needs to be fixed. The question remains: what should it state? Would the working group be content with the RFC 8420 method? ________________________________ From: Valery Smyslov <[email protected]<mailto:[email protected]>> Sent: Tuesday, September 23, 2025 3:03 AM To: Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>>; 'ipsec' <[email protected]<mailto:[email protected]>> Subject: RE: [IPsec] draft-ietf-ipsecme-ikev2-pqc-auth Hi Scott, The draft currently states that IKE will hash the signed octets (using the negotiated hash function) and then have ML-DSA/SLH-DSA sign that hash (which would involve applying a hash function again). actually the draft only specifies using the Identity hash, so there is no real hashing before passing octets to be signed to the signature algorithm. Thus, there is no double hashing - all the hashing takes place only inside ML-DSA or SLH-DSA. Regards, Valery.
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
