Re: SSH in ECC Internet Draft

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

Like der Mouse I currently know little about ECC, but I've got a few 
comments nonetheless.

In article <1160074485.7777.30.camel%merlot.certicom.com@localhost> you write:
>3.1.  Key/Signature Encoding
>
>   The ECC public key and signature are sent in the standard encoding
>   for ECC keys and signatures.  This requires ASN.1 DER encoding which
>   is specified in [7] and [8].

Using ASN.1 worries me a little, given the rate at which security holes 
are found in ASN.1 decoders.

>   The ecc public key has the following encoding:
>
>      string     "ssh-ecc"
>      ASN/DER    SubjectPublicKeyInfo
>
>   Here 'SubjectPublicKeyInfo' is defined as it is in Section C3 of SEC1
>   [4].

Conventionally, key format names beginning "ssh-" have been used for key 
formats invented specifically for SSH, while other names have been used 
for key formats imported from elsewhere.  Thus I'd suggest using a name 
not starting with "ssh-" here, say "sec1-ecc".

>4.2.  Implementation

>                    +----------------+----------------+
>                    |   Curve Size   | Hash Algorithm |
>                    +----------------+----------------+
>                    |    b <= 256    |     SHA-256    |
>                    |                |                |
>                    | 256 < b <= 384 |     SHA-384    |
>                    |                |                |
>                    |     384 < b    |     SHA-512    |
>                    +----------------+----------------+

You should cite [9] here as a reference for SHA-256 etc.

>   The hash H is computed as the HASH of the concatenation of the
>   following.

You haven't defined HASH here.

>5.1.  Description

>   2.  C OPTIONALLY verifies that the 'curve' has an acceptable level of
>       security compared to the bulk encryption algorithm chosen during
>       algorithm negotiation, a good reference for key strength
>       comparison can be found in [11].  If C accepts 'curve' then it
>       uses the associated domain parameters to generate an ephemeral
>       ECC public/private key pair.

What does it do if it doesn't accept 'curve'?

>5.2.  Implementation

>                    +----------------+----------------+
>                    |   Curve Size   | Hash Algorithm |
>                    +----------------+----------------+
>                    |    b <= 256    |     SHA-256    |
>                    |                |                |
>                    | 256 < b <= 384 |     SHA-384    |
>                    |                |                |
>                    |     384 < b    |     SHA-512    |
>                    +----------------+----------------+

Again, cite [9]...

>   The hash H is formed by applying the algorithm HASH on a
>   concatenation of the following:

And define HASH (or just refer to "the exchange hash algorithm").

>9.  Acknowledgements
>
>   The author would like to thank Douglas Stebila who wrote
>   draft-stebila-secsh-ecdh-01, the ECDH portion of this draft is
>   largely an updated version of his document.

Douglas Stebila is one of the authors -- it seems odd for him to be 
thanking himself.

>   [4]   Standards for Efficient Cryptography Group, "Elliptic Curve
>         Cryptography", SEC 1, September 2000.
>
>   [5]   Standards for Efficient Cryptography Group, "Recommended
>         Elliptic Curve Domain Parameters", SEC 2, September 2000.

SECG standards seem to have version numbers -- it might be worth quoting 
them here.

>   [6]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
>         Levels", RFC 2119, March 1997.

RFCs are usually listed before other references.

>   [7]   Internation Telecommunication Union, "Abstract Syntax Notation
>         One (ASN.1): Specification of basic notation", X. 680,
>         July 2002.
>
>   [8]   Internation Telecommunication Union, "ASN.1 encoding rules",
>         X. 690, July 2002.

That's "International", "X.680" (no space), "X.690", and "ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)", according to the 
ITU Web site.

>   [10]  National Institute of Standards and Technology, "Keyed-Hash
>         Message Authentication Code", FIPS 198, March 2002.

Is there any good reason not to reference RFC 2104 instead of FIPS 198?

-- 
Ben Harris