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

[Douglas Stebila <douglas%stebila.ca@localhost>]

> > 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.

> > Actually, why bake the names into the kex names at all? (as opposed  
> > to
> > sending a curve spec as a parameter).
>
> This is another case where SSH really needs an extension mechanism  
> like TLS.
> In TLS the curve parameters and point formats are negotiated via  
> extensions.

I'm afraid that's outside the scope of my lowly draft.  :)

> 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.

Points for debate:

1) Should the list of named curves be longer, for example, including  
all the NIST curves or all the SEC curves?

2) Should the named curves be named by their NIST name or their SEC  
name?  (nistp256 versus secp256r1)

3) Should we entirely remove the Base64(MD5(DER(OID))) optional  
encoding and entirely leave it to name@vendor-name?  My opinion is  
no:  Although name@vendor-name is the common mechanism for naming  
additional SSH mechanisms, elliptic curves in other standards are  
often named with OIDs which are universal.

Regards,

Douglas