Subject: ECC in SSH draft version -01

From: Jon Green <[email-masked]>
Date: Mon, 16 Oct 2006 13:09:26 -0400

Thank you for all the comments on draft-green-secsh-ecc-00.

I've addressed a lot of the concerns that were raised with a new version
of this draft draft-green-secsh-ecc-01. I submitted the new version to
the IETF, but I'm not sure if I made the deadline for drafts to be
posted, so I attached it to the message as well, while I wait for it to
be posted.

Specifically I addressed the problems with double negotiation within the
protocol and in doing so, made the ASN.1 in the document redundant, so I
moved away from ASN.1 messages. 

I'm would appreciate any comments you have on the revised version of the
draft.

Thanks, 
--
Jon Green
Research Intern
Certicom Corp.

---

From: Ben Harris <[email-masked]>
Date: Tue, 17 Oct 2006 23:02:24 +0100

>I'm would appreciate any comments you have on the revised version of the

The changes generally seem quite sensible, and in particular they 
address a problem I hadn't even got around to articulating with the old 
draft -- that a server's host key might use a curve not supported by the 
client.

>4.2.  Implementation
>
>   This document is concerned with describing the implementation of ECDH
>   in SSH, not the specification of the algorithm itself.  The algorithm
>   used for shared key generation is ECDH, the full specification of
>   which can be found in Section 3.3.2 of SEC1 [6].

I feel that it might be worth referring to the primitive specified in 
that section by name, especially since it's not the one that SEC1 calls 
"elliptic curve Diffie-Hellman".

I note that the output of ECDH is a field element, so you should
probably specify how that gets transformed into the integer K required
by SSH.  I'd guess that you use the FieldElement-to-Integer conversion
in section 2.3.9 of SEC1, but you don't seem to say so.

The same applies to ECMQV.

>   The server's host keys are used in shared key generation; therefore,
>   the named curve used to generate them is the curve that must be used
>   by the ECMQV algorithm.  Care should be taken that the server's host
>   key is sufficiently strong to ensure that the ECMQV algorithm isn't
>   the weakest point in the SSH encryption suite.

_Something_ has to be the weakest point.  Why shouldn't it be ECMQV?

>   "secg-ecc-standard" tells the server that the clients local security
>   policy has not disabled any of the required curves specified in
>   Appendix A and is analogous to sending "secg-ecc-1.3.132.0.37,secg-
>   ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-ecc-1.2.840.10045.3.1.7".
>
>   "secg-ecc-extended" tells the server that the client supports all of
>   the curves specified in Appendix A and is analogous to sending "secg-
>   ecc-1.3.132.0.38,secg-ecc-1.3.132.0.35,secg-ecc-1.3.132.0.37,secg-
>   ecc-1.3.132.0.36,secg-ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-
>   ecc-1.2.840.10045.3.1.7,secg-ecc-1.3.132.0.27,secg-ecc-
>   1.3.132.0.26,secg-ecc-1.3.132.0.33,secg-ecc-1.2.840.10045.3.1.1,secg-
>   ecc-1.3.132.0.1".

I'm a little suspicious of these.  They make it harder to use existing 
code for processing algorithm lists for the sake aof a few bytes in each 
KEXINIT, which I think is a poor trade-off.

>   When the server forms its 'server_host_key_algorithms' name-list it
>   MUST include only the algorithm from the "ecmqv-sha2-*" family that
>   corresponds to the named curve used to produce its ECC host keys.

That seems to require that any used with an ECC host key MUST support 
ECMQV.  I doubt that is what you intended.

-- 
Ben Harris

---

From: Joseph Galbraith <[email-masked]>
Date: Mon, 23 Oct 2006 12:32:00 -0600

> KEXINIT, which I think is a poor trade-off.

I thought there was a ceiling on the length of the name-list
strings during key exchange (something like 256), but I can't
find it now.

If I'm blind and not dreaming, then the string above is probably
a bit on the long side...

If I dreaming and not blind on the other hand, than I think
I agree... the 'meta-names' will just make implementation
more difficult.

Thanks,

Joseph

---

From: der Mouse <[email-masked]>
Date: Mon, 23 Oct 2006 14:55:02 -0400 (EDT)

> I thought there was a ceiling on the length of the name-list strings
> during key exchange (something like 256), but I can't find it now.

There is a ceiling, in that too large a list will blow out the
35000-octet minimum packet size limit.  But it's a long way from 256.

My own implementation offers

[email-masked]
blowfish-ctr
aes128-ctr
blowfish-cbc
aes128-cbc
aes192-cbc
aes192-ctr
aes256-cbc
aes256-ctr
idea-cbc
[email-masked]
[email-masked]
3des-cbc
3des-ctr
arcfour
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]

which is just a hair under 1K of algorithm names, and, while I haven't
tested it extensively against a wide variety of implementations, I
haven't run into anything that either objects or breaks in response to
that.

> If I dreaming and not blind on the other hand, than I think I
> agree... the 'meta-names' will just make implementation more
> difficult.

That is my own take on it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B