On Jul 22, 2012, at 4:15 PM, Tero Kivinen wrote: > Dan Harkins writes: >> We've been through nearly 40 revisions of this protocol (18 for IKEv2, >> another >> 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it >> still >> needs hacks to add some new elliptic curves-- either N new authentication >> modes for N curves, or a new unified and general ECDSA in addition to the >> existing 3 for ECDSA (!!!)-- > > You forgot the IKEv1 drafts too, as IKEv1 does the ECDSA at the same > way than IKEv2 (they both come from the same RFC), so they should also > be counted as revisions. > > And, no, I have no idea why the people who added ECDSA did add it that > way.
I don't know either, but I can guess. With RSA the hash is much smaller than the signature (128-512 bits vs 1024-4096 bits) so we use the PKCS#1 structure that also describes the hash. So you don't need to specify the hash up front - it's encoded in the signature itself. With ECDSA, the hashes are the same sizes as the signatures, so there's no room within the signature to encode the hash algorithm. You need to know what it is by some other means. So they chose to encode it using the AUTH method. Not very economical in terms of protecting the scarce resource of auth methods. My suggestion only improves this by making each curve go with a specific hash (specified in the document, not in the protocol). And you can probably replace the hashes with their SHA-3 (or GOST) equivalents by using the reserved fields in the AUTH payload. Regardless of what we do with the Brainpool curves, we also need to be ready for vanity curves, and there's no telling how many we're going to have. openssl/crypto/ec/ec_curve.c has several dozens of them, and I wouldn't want us to have to fight over allocation for each new curve. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
