Re: ECC in SSH draft version -01

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <1161018566.28037.13.camel%merlot.certicom.com@localhost> you write:
>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.

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