IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: SSH in ECC Internet Draft



Most of my comments will be copy-edit remarks, because I do not know
enough about elliptic-curve crypto to say anything intelligent about
that.  (I hope to someday dig up the info, but the references you give
are mostly things I don't currently know how to find.)

This document specifies many packet fields as having type "ASN/DER".
I'd prefer to see it spelled out more precisely what this means.  Does
it mean that the DER-produced octet string is exaclty what appears in
the packet at that point?  Does it mean that the packet contains a
"string" which contains the DER-produced octet string?  Something else?

>        +-----------+-----------------------------+-------+---------+
>        | Symmetric |  Discreet Log (eg. DSA, DH) |  RSA  |   ECC   |
>        +-----------+-----------------------------+-------+---------+

ITYPM "Discrete".

This table is also meaningless unless accompanied by a way of comparing
the amount of computation demanded by, say, a 240-bit elliptic curve
key with the computation demanded by a 2048-bit RSA key.

>    Protocol fields and possible values to fill them in are defined in
>    this set of documents.  As an example SSH_MSG_KEX_ECDH_INIT is
>    defined as follows.
> 
>       byte       SSH_MSG_NUMBER
>       string     pK, public key octet string.

s/MSG_NUMBER/MSG_KEX_ECDH_INIT/ surely?

>    as the public key algorithm through key exchange negotiations the
>    servers long term ECC key pair (host keys) are used for
>    identification and verification.

s/servers/server's/ and s/are/is/ ("key pair" is singular).

>    the SSH implementation details, specification of the algorithm is

s/,/;/

>    public keys.  Using its own key pair and the other's public key both
>    the client and the server derive the same shared secret key using
>    ECDH.

s/key both/key, both/

>    3.  S MAY validate 'cPK' using for example algorithm A.16.10 of [12].

s/ for example/,&,/

>    The size of the selected curve SHOULD be greater than 160 bits, and
>    preferably at least 224 bits.  The size of the curve used SHOULD be

Either s/,// or s/ and// here.

>    Specification of the message numbers SSH_MSG_KEX_ECDH_REQUEST,
>    SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are found in
>    Section 7.

s/are/is/ (or s/Specification/&s/).

>    another entity.  Both entities roles are analogous in the algorithm.
>    Using their own key pairs and the other entities public keys, both

s/entities/&'/ on each line.

>    The following is an informal discussion of ECMQV key exchange and
>    verification for a formal description see Section 5.2.

s/ for /;&/

>    is not in the clients name-list then both sides MUST disconnect.

s/clients/client's/

>    The server's host keys are used in shared key generation, therefore

s/, therefore/; therefore,/

>    key is generated with sufficient strength to ensure that the ECMQV

s/generated with sufficient strength to ensure/sufficiently strong/

> 6.1.  ssh-ecc
> 
>    The "ssh-ecc" method specifies Elliptic Curve digital signature
>    algorithm (ECDSA) for use in signing communications with ECC host
>    keys.  When used with ECMQV "ssh-ecc" provides ecmqv with a host key.
>    This method is discussed in Section 3.

This makes it sound as though ssh-ecc host keys and ecmqv key exchange
are not independent - that it is not possile to use one without the
other.  If true, I think this is a bad idea, if only because the
negotiation framework does not support this kind of tied negotiation.

>    When lists of curves need to be sent to negotiate mutually supported
>    curves they are sent as a sequence of unique ASN.1 OIDS.  The ASN.1

Why is there a hard limit on the size of a list of curves, especially a
limit that's a magic number like 12?  Surely it would be better to
leave this extensible?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B



Home | Main Index | Thread Index | Old Index