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

[James Blaisdell <JBlaisdell%mocana.com@localhost>]

I've implemented draft-06: ECDH and ECDSA.  It was very simple to refactor TLS EC code to support SSH.  The base64 encoding is ugly, but I agree it's necessary.  IMO - The @domain approach is uglier and the thought of ASCII encoding OIDs is even nastier.  Since the base64 encoded OID string is static, I don't bother to decode, I simply know this string maps to a curve.  

Earlier on this thread, it was suggest that perhaps the client and server could fall back, if the host key type did not match.  This would add many more messages to the protocol.  I recommended to Douglas to append the base64 to the base type (i.e. ecdsa-sha2-<BASE64>) to avoid this issue.  I think it's the correct approach, and most true to SSH protocol.  Adding TLS-like hello extension would be messier, and break interoperability with all preexisting implementations in the field.  

It seems the base64 oid is the only controversial item in this draft.  If so, it's a minor issue.  I would very much like to see this draft version move to RFC.  It's well written, easy to implement, matches other SSH RFCs in naming convention and feels complete imo.  

Thank you,

James

-----Original Message-----
From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Jeffrey Hutzelman
Sent: Tuesday, April 14, 2009 8:11 AM
To: Douglas Stebila; Peter Gutmann
Cc: djm%mindrot.org@localhost; ietf-ssh%NetBSD.org@localhost; jhutz%cmu.edu@localhost
Subject: Re: New version: draft-green-secsh-ecc-06

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