>>> 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 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. As I said in an earlier message, adding hash algorithm flexibility is a more general topic concerning not only ECDSA. It probably requires much more than simply defining a new auth method and specifying a rule, which hash function to chose for which ECDSA bit length. > > FIPS 186-3 (The Digital Signature Algorithm) specifies that security > strength levels of DSA are a minimum of the security strength of the > hash algorithm and the (L,N) pair from the domain parameter set. If > one wished to achieve a security strength level with DSA that would > be valid, according to NIST, "beyond 2030" one would need to use > SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature" > (authentication method value of 3) so that wouldn't work. > > Given that SP 800-57 requires that 80 bits of strength only be used > through 2010 (and SHA-1 does not provide more than that) and it > is now 2012 it appears that IKEv2 is not capable of producing a > signature of sufficient strength for certain customers (they might not > be your's but they do exist, and there's probably more of them than > there are people clamoring for AES-XCBC MAC). > This is definitely an issue when using DSA with IKEv2, and I do not doubt that something should be done, but I don't think that this needs to be coupled with an effort to specify a curve-independent ECDSA auth method. > 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. > 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. > 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. Johannes > Dan. > > > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
