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]
