Re: New version: draft-green-secsh-ecc-06

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

--On Tuesday, April 14, 2009 03:53:12 PM +1000 Douglas Stebila 
<douglas%stebila.ca@localhost> wrote:

> > > I have to say that I really dislike the Base64(MD5(DER(OID)))
> > > encoding of
> > > curve names into the kex method names. Why not just use the SEC
> > > names?
> >
> > Oh, so it wasn't just me :-).  My reaction to seeing this was "did
> > someone
> > lose a bet or something...".
>
> As I mentioned, this was a change that my IETF document shepherd asked me
> to make in going from -02 to -03.  I agree it's ugly.

That was me.  The particular encoding I suggested is the same one we used 
in gss-keyex for GSS-API mechanisms, which are also named by OID's.  I 
agree it's ugly, but I don't know of any better alternatives (ironically, 
the SASL WG is working on a better alternative for GSS-API mechanisms, too 
late for us, but it doesn't apply to OID's in general).

It would be fine to name the kex methods by names, if there are such, but 
using an OID encoded in ASCII won't work; OID's can be arbitrarily long and 
you'll quickly run out of space.

> > Having said that, in practice everyone (well, among TLS
> > implementors) has
> > settled on a small number of popular curves and that's it (which is
> > quite
> > convenient, you don't even have to worry about extensions, just go
> > with P256
> > and everything'll support it).  I'd define a few fixed names for the
> > well-known curves that everyone ends up using (the NIST ones,
> > basically) and
> > leave the strange stuff to the usual name@vendor-name mechanism,
> > which is
> > exactly what it was meant for.
>
> If the consensus on this mailing list is that using a few fixed names is
> fine, then I am willing to make that change.
>
> My preference would be the following:
>
> Method names are ecdh-sha2-[identifier] and ecdsa-sha2-[identifier],
> where [identifier] is
> 	nistp256 -- REQUIRED (Suite B)
> 	nistp384 -- REQUIRED (Suite B)
> 	Base64(MD5(DER(OID))) -- OPTIONAL
> with the additional proviso that, if the curve in question is in fact
> nistp256 (== secp256r1) or nistp384 (== secp384r1), then implementations
> MUST use the nistp256/nistp384 naming convention and MUST NOT use the
> Base64(MD5(DER(OID))) naming convention.
>
> The rationale for this compromise is as follows.  It seems as if we
> expect the vast majority of implementations to be aiming for Suite B
> which is nistp256 and nistp384. Those implementations need never worry
> about the ugly names.  For implementations that want to go beyond Suite
> B, they can use the ugly (but universal and extensible) names.

Note that this is similar to the compromize we made for mod-p DH keyex, 
where we have fixed names for a few groups, plus a "group exchange" method 
that allows negotiation of a specific group once the method has been 
selected.  However, that does have the two-level negotiation problem.

-- Jeff