Subject: Re: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer

From: Jan Pechanec <[email-masked]>
Date: Tue, 11 Nov 2008 16:59:19 +0100 (CET)

On Wed, 1 Oct 2008, Douglas Stebila wrote:

> A new version of the ECC in SSH draft is now available for review.
>
> http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-03.txt

	hi Douglas,

	I like the draft, and have some comments.

	- section 1, ECMQV has been dropped from the National Security
Agency's Suite B. I don't know when but it's not there now:

	http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

	I'm wondering if an inclusion of that in this draft may not cast 
some shadow on it in general as including something that might have 
potential legal issues if used.

	- section 4, this might be just a language issue; does this imply 
that the remote key pair is ephemeral as well or not? Or would it be better 
to say "and ephemeral remote public key"?

   The Elliptic Curve Diffie-Hellman (ECDH) key exchange method
   generates a shared secret from an ephemeral elliptic curve local
   private key and remote public key.

	- section 4, you may want to reference RFC 4251, 4.1 (Host Keys) and
section 9.3.4 (Man-in-the-middle) in the "*" paragraph. Same in section 5.
Or it could be at one common place so that it's not duplicated.

	- section 4, "The exchange hash H is computed as the hash of the
concatenation of the following.", please change NL to LF. NL is EBCDIC's
notation, not ASCII.

	- section 4, you may want to change "version string" to
"identification string" since that's what RFC 4253 almost exclusively uses.
Same in 5.

	- section 5. I don't know very much about ECC so I have a question. 
I understand that we can use implicit server authentication since server's 
private key is already involved in the generation of the shared secret. So, 
HMAC instead of the ECDSA is then used just because it's faster?

	- is it needed to include shared secret in the hash input when we 
already use it in HMAC on the resulting hash? I'd say to break it is equally 
difficult whether the secret is there or not.

	- section 9.2, I like that you put the command sequence that
generates Base64(MD5(DER(OID))). However, claiming that you can run it on
many unix-like systems seems quite strong to me. "oid" is not found on any
system I tried, be it FreeBSD 6.1, Gentoo 1.12.11.1, or OpenSolaris. What's
more, "xxd" is part of ViM. Not sure if those details should be part of the
RFC but at least "oid" is quite generic name, I can't find what "oid -i" is
supposed to do exactly; I just guess "-i" means an input file, not a 
specific type of output.

	wrt the SSH protocol I think it should work as defined but obviously 
a reference implementation might reveal more.

	cheers, J.

--
Jan Pechanec

---

From: der Mouse <[email-masked]>
Date: Tue, 11 Nov 2008 12:24:44 -0500 (EST)

>    private key and remote public key.

Maybe "...from ephemeral elliptic curve local private and remote public
keys"?

> a reference implementation might reveal more.

I think reference implementations are a bad idea; I much prefer sample
implementations.  (The difference is that a reference implementation by
definition _is_ the spec in an operational form, and if it disagrees
with some other spec, there's no a priori way to tell which is wrong.
If a sample implementation disagrees with the spec, there's no question
- the sample implementation is wrong.)

/~\ The ASCII				  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

---

From: Douglas Stebila <[email-masked]>
Date: Sat, 15 Nov 2008 20:55:20 -0500

Thanks for the comments, Jan.  I've implemented all of the changes you  
suggested and am responding to your other questions below.  A new  
draft will appear next week when the Internet Draft submission tool is  
back online.

> potential legal issues if used.

While it's no longer part of NIST Suite B, it is a useful protocol  
that I am to understand a number of organizations wish to use.  I have  
added language clarifying that the ECMQV portion is optional.

> HMAC instead of the ECDSA is then used just because it's faster?

That's right.

> difficult whether the secret is there or not.

I suppose it's not strictly necessary in the context of HMAC.  If the  
value H in that section is ever used for another purpose in the  
context of the SSH protocol, then it would be necessary to have it in  
there for authentication purposes.  It doesn't hurt to keep it in, so  
that is my preference.

> supposed to do exactly; I just guess "-i" means an input file, not a

I've clarified the language to be clear that these are not standard  
Unix commands but could be installed from the URLs given.

Thanks,

Douglas