The EdDSA approach certainly has its upsides (such as being simpler and removing the 'you need to document that the IKE hash function needs to be as strong' objection that Quynh raised).
My concern would be the short-term implementation difficulty. Could we have some implementors chime in (either that they already support RFC 8420 or that it wouldn't be difficult to add)? Minor correction: ECDSA fits nicely into the hash-and-sign paradigm, and RFC 7427 has the hash algorithm being negotiated separately. This does not change your point (ECDSA, at this point, is not what we're doing going forward). ________________________________ From: John Mattsson <[email protected]> Sent: Monday, September 22, 2025 10:29 AM To: Dang, Quynh H. (Fed) <[email protected]>; Scott Fluhrer (sfluhrer) <[email protected]>; ipsec <[email protected]> Subject: Re: [IPsec] Re: [EXTERNAL] draft-ietf-ipsecme-ikev2-pqc-auth Scott Fluhrer wrote: EdDSA has a similar constraint that it is also does not use a 'hash-and-sign' paradigm internally - RFC 8420 provides an alternative method (avoid the IKEv2 hash operations entirely and present the 'signed octets' string to the EdDSA operation); ML-DSA and SLH-DSA would both fit cleanly into this. However, I expect that implementing this on IKE implementations that do not already support RFC 8420 would be more work. ECDSA, ML-KEM, and SLH-DSA, FN-DSA, and all future algorithms (like MAYO, SNOVA, etc.) can be expected to work in this way. I think the way forward is to avoid the IKEv2 hash operations entirely and present the 'signed octets' string to the ML-DSA and SLH-DSA. (I would not say that EdDSA has a ‘constraint’ I would say that IKEv2 has outdated contraints/assumptions). John From: Dang, Quynh H. (Fed) <[email protected]> Date: Monday, 22 September 2025 at 16:01 To: Scott Fluhrer (sfluhrer) <[email protected]>, ipsec <[email protected]> Subject: [IPsec] Re: [EXTERNAL] draft-ietf-ipsecme-ikev2-pqc-auth The draft says “pure mode”. But it says “(see Table 2 in Section 10 of [I-D.ietf-pquip-pqc-engineers]) “ in the second paragraph of Section 4, but the table 2 in that referred draft does not say anything about pure mode or prehash mode. The selection of “pure mode” is stated in Section 3.2. Regards, Quynh. From: Dang, Quynh H. (Fed) Sent: Monday, September 22, 2025 9:44 AM To: 'Scott Fluhrer (sfluhrer)' <[email protected]>; ipsec <[email protected]> Subject: RE: [EXTERNAL] [IPsec] draft-ietf-ipsecme-ikev2-pqc-auth Hi Scott and all, I think the draft is not clear on what mode is used (pre-hash or pure). If the pure mode is used, then some warning about the hash function choice from the IKE’s negotiation would be good (not to reduce the security of the signing algorithm). In this case, IKE hashes with the negotiated and agreed hash function, then the signing algorithm has its own internal hash function. If the pre-hash is used, then the pre-hash algorithm can come from the IKE’s hash function negotiation, and it should meet the security strength of the signing function. Regards, Quynh. From: Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> Sent: Monday, September 22, 2025 9:17 AM To: ipsec <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] [IPsec] draft-ietf-ipsecme-ikev2-pqc-auth I believe that this draft is close to working group last call - it is mostly "take the existing protocol, and replace the RSA signature with an ML-DSA or SLH-DSA signature". However, there is one point that is less trivial, and I would prefer that, if someone has an opinion on this, we address it before we proceed (and this point is getting a bit far into the cryptographical weeds, but still we should still make a decision that people are comfortable with). The original IKE architecture was designed around RSA - it would take the initiator's/responder's signed octets, hash them using a negotiated hash function, and them perform the rest of the signature generation/verification process. This doesn't work cleanly with ML-DSA or SLH-DSA, because they generally do hashing internally, using a hash function they specify (and this hash function is not negotiated). 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). While this works, that is not the only possible option (and this is what I would like to get people's opinion on). Here are two obvious alternative options: * ML-DSA and SLH-DSA also have a 'prehash' option, which is designed specifically for externally hashed data (which is what we have in this case). However, there are several possible practical drawbacks (whether it will be commonly implemented and that uses different certificate OIDs which may not be widely implemented) that caused us to not select this option. * EdDSA has a similar constraint that it is also does not use a 'hash-and-sign' paradigm internally - RFC 8420 provides an alternative method (avoid the IKEv2 hash operations entirely and present the 'signed octets' string to the EdDSA operation); ML-DSA and SLH-DSA would both fit cleanly into this. However, I expect that implementing this on IKE implementations that do not already support RFC 8420 would be more work. Section 7 of the draft has a lengthier discussion of this. So, does the working group have strong (or even weak) opinions on this?
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
