RE: deaft-gree-sedsh-ecc-08: small correction

["Igoe, Kevin M." <[e-mail]>]

You are correct, MQV was thrown out of Suite B some time ago
and we should rephrase this statement to reflect that.  I
view leaving MQV in this draft as harmless.  Yes, currently
there are Intellectual Property issues involving MQV, but that
may well change in the future.

As to checking for the point at infinity in ECDH, I'd
rather have that issue addressed in a document that is
clearly directed at ECDH rather than having it hidden 
in a document that only peripherally touches ECDH.
I'll be putting out a "Suite B for Secure Shell" document
in the near future and plan to cover such issues in there.


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Damien Miller
> Sent: Friday, August 13, 2010 1:30 AM
> To: Igoe, Kevin M.; Douglas Stebila
> Cc: [e-mail]
> Subject: Re: deaft-gree-sedsh-ecc-08: small correction
> 
> On Tue, 16 Jun 2009, Igoe, Kevin M. wrote:
> 
> > In the Introduction to draft-green-secsh-ecc-08 we find
> >
> >    In the interest of adding Suite B algorithms to SSH this document
> >    adds three ECC Suite B algorithms to the Secure Shell arsenal:
> >    Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve
Diffie-
> >    Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm
> >    (ECDSA), as well as utilizing the SHA2 family of secure hash
> >    algorithms.
> > Slight error here: ECMQV is no longer part of Suite B.  For sake of
> > correctness, I'd suggest something like the following:
> >
> >    In the interest of adding Suite B algorithms to SSH this document
> >    adds two ECC Suite B algorithms to the Secure Shell arsenal:
> >    Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital
> >    Signature Algorithm (ECDSA), as well as utilizing the SHA2 family
> >    of secure hash algorithms. Additonally, support is provided for
> >       Elliptic Curve Menezes-Qu-Vanstone (ECMQV).
> 
> Why not drop ECMQV from the draft entirely? AFAIK it is patented,
> which is enough to stop us (OpenSSH) from implementing it. I think
> new KEX methods need a very good justification, since they represent
> a significant part of the pre-auth attack surface.
> 
> Also on the -08 draft, shouldn't the client and server in ECDH reject
> public keys from the peer that are points at infinity? Are there
> other degenerate values to worry about?
> 
> -d