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

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

On 2009-Apr-14, at 2:06 PM, Damien Miller 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?

Not all curves have SEC names.  There exist standardized curves that  
have OIDs but not SEC names.

The most relevant curves in my mind are the NIST Suite B curves, which  
are a subset of the NIST curves, which are a subset of the SEC curves,  
which are a subset of all curves with OIDs, which are a subset of all  
curves.  One could draw the line anywhere, and currently the line is  
drawn at OIDs.  I would need more feedback from implementers as to  
whether only SEC curves suffice.  I recognize that for many  
implementers the driving force right now is NSA Suite B compliance,  
which requires only secp256r1 or secp384r1.

As for the Base64(MD5(DER(OID))) encoding: I was told that not all  
OIDs are guaranteed to be sufficiently short to keep the overall  
method name down to no more than 64 characters as required by RFC 4251  
Section 6.  This mechanism guarantees sufficiently short method names  
which are extensible and (almost certainly) unique.

> Actually, why bake the names into the kex names at all? (as opposed to
> sending a curve spec as a parameter).

This would require a second round of negotiation, which could fail.   
Suppose that two implementations agreed to use ecdh-sha2 and then in  
the subsequent curve negotiation discovered that they had no common  
set of curves (this may be possible as REQUIRED curves can still be  
disabled by local security policy).  I don't believe SSH has a  
mechanism for dealing with a failed kex method by moving on to the  
next method in the list of mutually supported kex methods, but I could  
be mistaken about that.

(For comparison, when ECC was added to TLS a similar problem arose and  
they used extensions in the client_hello and server_hello messages to  
transport the list of supported curves.

I don't know any way other way around this problem, but if you know of  
one I'd be happy to consider it.

> Do the many ECC patent apply to the methods described in this draft?  
> It
> seems to lack any section on IPR.

Other IETF documents involving ECC, such as RFC 3278 (ECC in CMS) and  
RFC 4492 (ECC in TLS) do not include a discussion speculating on how  
the documents are affected by ECC patents.  I am not a lawyer and do  
not feel qualified to include any speculation of my own in the document.

> The "Security Considerations" section talks about the possible need to
> replace SHA2 with other algorithms, but the name "sha2" is baked into
> the kex method name. Should the hash algorithm be a parameter too?

That's an option, although one that I don't think is worth pursuing at  
this point.  The SHA-3 competition is a long way from being done, so  
SHA-2 is the gold standard right now.  If there's a desire to see  
SHA-3 adopted in SSH, it would not be hard to create a short RFC  
indicating that SHA-3 could be substituted fro SHA-2, and this draft,  
while not explicitly saying how to do it, is very suggestive.

Douglas