Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS

[Nico Williams <[e-mail]>]

On Wed, Jun 10, 2015 at 01:27:17PM -0400, Michael StJohns wrote:
> On 6/5/2015 10:06 PM, Simon Josefsson wrote:
> >Are you saying it would be useful to also specify certificate formats
> >for Curve25519 ECDH keys?
> 
> Sorry - I missed this in the pile.
> 
> And yes for Curve25519.
> 
> Here's my thoughts:
> 
> [...]
> 
> The nice thing about this scheme (It's called a C(2,2) scheme in
> NISP SP800-56A parlance), is that you don't need to sign anything
> during a key agreement handshake.  You still need traditional
> signature schemes over the certificates, but you don't actually need
> them in the handshake.

RSA key transport was nice because it was faster than DH + signatures.

Now that PFS matters that consideration goes the way of the dodo.  It's
got to be key agreement + authentication, which means either key
agreement with signatures, or two key agreements.

(Using DH with fixed public keys goes back to the invention of DH
itself, and this was deployed way back when.  E.g., AUTH_DH.  This is
why PKIX supports key agreement certificates.  Combining DH for
authentication with DH for PFS is an obvious idea.)

And besides, with ECC and curves like Curve25519, *two* ECDH exchanges,
one of which has a certified public key on the server side (the other
being ephemeral, for some value of "ephemeral"), can go faster than one
signed ECDH exchange.  How much, if at all, may depend on what curves
and implementations.

> There are other schemes where one side only has ephemeral keys (e.g.
> client without cert) where this still works - you end up with:

Right, and which would be the common case on the Internet.

> This just works with the existing EC Prime and F2M curves as the key
> pairs can be used with both ECDSA and ECDH.

Is that safe?

> In any event, going ahead and creating a certificate format for
> Curve25519 at the same time you do ED25519 probably makes sense
> given the two algorithms are family members and appear to share a
> representation.

Sure, but doing it separately works too.  Whatever makes the spec go
faster.

Nico
--