>> By generic ECDSA methods, I did not mean hash-independent but only >> curve-independent. >> >> At least for SHA-1/SHA-2, the mapping between size of the curve and hash >> function could be fixed in an RFC. The hash >> length shall not be smaller than the bit length of curve parameters >> (FIPS-186-3), and there is no need to choose an >> SHA-2 function longer than the minimum one meeting this requirement. > > If the mapping between curve and hash function is fixed then I don't > see what you mean by "not hash-independent but only curve-independent". > Seems that there is nothing independent, it's all fixed.
I have the impression that we misunderstand each other. The solution that I propose is to define one new auth method ECDSA_generic which indicates that - the curve shall be taken from the certificate - the hash function shall be the minimum SHA-1/2 function matching or exceeding the security level of the curve. This method is flexible w.r.t the curve but not w.r.t the hash function, and that is what I called "not hash-independent but only curve-independent". Maybe the term "curve-flexible but not hash-flexible" is better. This approach is exactly the one followed for DSA (DSS Digital Signature), except that the latter one was limited to SHA-1. Thus, a curve-independent ECDSA method would be more consistent with the existing DSA method. This is the reason why I objected to your assertion of our approach being a "hack". But maybe you didn't refer to this approach at all? > >>> So to actually address this in the hash-specific canonical way >>> requires new auth methods for different permutations of DSS with >>> SHA-224, SHA-256, SHA-384, and SHA-512 as well as different >>> permutations of ECDSA with brainpool curves using the 5 different >>> SHA varients. But this is getting, as you say, "cumbersome". >>> >> As said above, I don't see the need to allow, for instance, the Brainpool >> p256 curve to be used with any hash function >> other than SHA-256. > > And there are 7 new brainpool curves so that's 7 new auth methods > plus 4 new ones to deal with the non-EC version of DSA for a total > of 11 new auth methods to go along with the existing 4. 15 different > auth methods just for the digital signature standard! > Not with the approach I proposed: there is only one method ECDSA_generic. Note, that for DSA (on EC), it would also be sufficient to specify a new auth method DSS_key_length_defined_hash accompanied with the requirement to choose the hash function as the smallest SHA-2 function meeting the minimum requirements of FIPS-186-3. >>> Of course one can decide not to use the hash-specific canonical >>> technique and come up with "generic DSA" and "generic ECDSA" to >>> address this but then we have the unfortunate state of hash-specific >>> (EC)DSA methods and "generic" methods and now it's getting ugly >>> (and hack-ish). >>> >> Such a co-existence of different approaches would also be the case if a >> curve-independent (but hash-specific) ECDSA >> method was specified, and I agreee that this is a bit unfortunate. But >> this is not a major issue compared to alternative >> of specifying separate methods for each curve in an 8 bit registry. > > Yes, it is unfortunate. What's also unfortunate is that the 11 auth > methods mentioned above (plus the 3 existing ECDSA auth methods) > will probably have to be duplicated for SHA-3 thereby eating into this > "scarce resource" of an 8-bit registry even further. We have the choice: Either spending many assignments out of the 256 available, or to specify a generic auth method deviating from the approach previously tken for ECDSA (but being in accordance with the approach taken for DSA). > >>> Instead of either negotiating a complete ciphersuite (the way TLS >>> does) or individual components (the way IKEv1 did), IKEv2 does both >>> and gets the worst of both worlds. >>> >> >> Means to negotiate the hash function could be specified as discussed >> earlier in this thread, but of course this is a >> more significant change. And I am not sure if this is necessary, given the >> clear recommendations of FIPS 186-3. > > I am not advocating the mixing-and-matching of curves and hash > functions of different security levels (and therefore one could argue > to fix them) but it should be noted that IKEv2 allows all sorts of mixing > and matching of ciphers, hash algorithms, and D-H groups of different > security levels to be negotiated-- AES-256 with the 768-bit DH group > authenticated with ECDSA using NISTP384 with SHA-384 and key > derivation using SHA-1. Why would someone do this? I have no idea. > Can someone? Yes. Is there a reason to enforce a "no mix-and-match" > policy on some primitives and a "laissez faire negotiation" policy on > others? No, at least not a good one. > I assume, the reason why the hash function is not negotiated is that at the time IKEv2 was specified there was mainly one hash function giving adequate security in practical use. > The point is, that the IKEv2 design was quite myopic-- if there are > to be different permutations of curve-hash as separate auth methods > then it shouldn't have been made a "scarce resource" of an 8-bit > registry. You're right that fixing all this stuff that you describe as > "cumbersome" and "unfortunate" would be "a more significant > change". I think it might be worth trying and given the poor adoption > of IKEv2 now's the time to fix it with IKEv3 before it's too late. > I doubt that you can get a WG consensus on doing this. I am more interested in a short term solution, and for this I am prepared to do without hash-flexibility. Johannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
