On Mon, July 23, 2012 12:15 pm, Johannes Merkle wrote: >>>> If we're gonna recharter, maybe we should just work on an IKEv3 >>>> because >>>> the problems in IKEv2 are becoming apparent. This "new authentication >>>> mode" >>>> suggestion, or the need for a "generic ECDSA" algorithm are just hacks >>>> that >>>> should not be necessary for a properly defined protocol. In addition, >>>> the >>> >>> I do not agree. The generic definition of the ECDSA auth method is >>> analogous to the auth methods defined for RSA and DSA >>> keys, and thus, is rather the proper (canonical) way to define it than >>> a >>> hack. >>> Of course, the fact than there are already 3 specific auth methods for >>> ECDSA (which are not canonically defined) makes >>> specification of a generic ECDSA method more cumbersome. >> >> With RSA the hash algorithm is encoded into the padding so there is >> no real need to independently agree on a hash algorithm. For DSA, > > No, in RSA PKCS#1v1.5 padding (which is currently the only supported > padding in IKEv2), the hash algorithm is *not* > encoded in the padding. Only the length of the length of the hash value > can be determined due to the reserved zero octet > leading the hash value. For SHA-1 and the SHA-2 hash functions, the length > also determines the function, so your > assertion in in some way true for these functions. However, RFC 5996 does > not restrict the hash function to these. As > soon as one of the SHA-3 contributions is used, the function can not be > determined from the padding, as SHA-3 > contributions were required support 224, 256, 384, and 512-bit message > digests, exactly the lengths generated by the > SHA-2 functions.
I see that Scott Fluhrer has already responded to this; I agree with Scott. >> I disagree. The DSA algorithm definition is hash-specific so the hash- >> specific ECDSA auth methods are the canonical way. Let me point >> out, though, that canon law is not necessarily correct and this is an >> example. > > 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. >> 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! >> 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. >> 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. 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. Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
