Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

[Yoav Nir <[e-mail]>]

On Jan 13, 2014, at 5:22 AM, Watson Ladd <[e-mail]> wrote:

> On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson <[e-mail]> wrote:
>> Dear WG,
>> 
>> I may have missed to announce this document before, since some people
>> appear to have missed it.  This email is an attempt to introduce the
>> draft to the TLS WG properly.
>> 
>> This draft started out as specifying Curve25519 ECDHE key agreement for
>> TLS, back on September.  Manuel Pegourie-Gonnard jumped in as co-author
>> and has added details on public/private key representation, shared
>> secret computation, and test vectors, for the -02 draft.
>> 
>> In the latest -03 version of the draft, I have changed the document to
>> specify EC Named Curve code points for all "additional elliptic curves"
>> (i.e., Curve25519, E382, M383, Curve3617, M511, E521).  Some of the
>> Curve25519-related text may no longer be applicable to all curves, but
>> hopefully that can be fixed later on.
>> 
>> The latest draft is here:
>> http://tools.ietf.org/html/draft-josefsson-tls-curve25519-03
>> 
>> The additional curves come from the following CFRG draft, and my current
>> thinking is that our draft (for TLS) would stay in sync with the list of
>> curves in the CFRG document.
>> 
>> http://tools.ietf.org/html/draft-ladd-safecurves-02
>> 
>> We'd appreciate general feedback on the draft, especially if there is
>> any interest in adopting this document, and particular feedback on the
>> following points:
>> 
>> 1) Do we need all these curves defined for TLS?  What is the selection
>>   critera for including/exluding some of the curves?  Is that a TLS
>>   process, or an CFRG process?
> 
> It's unclear. Eric Resola (in a cousin n-removed from this email)
> seems to think that
> CFRG should do it, but unless he asks the CFRG chairs there doesn't seem to be
> a process for this conversation to happen. Part of the reason is that
> Curve25519 is
> secure, so in some sense there is nothing to discuss on the CFRG end.
> It comes down to
> "what should be supported" and efficiency argues Curve25519 should be
> in the mix.

Or you can do the equivalent of the signature authentication in IKEv2 draft:
http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-04

Just create a draft for a TLS extension that allows you to specify a curve and point format as OIDs. Not sure whether that's a good idea, though.

> The easiest solution is someone to ask if anyone disagrees, and if no
> one does, consider
> the security conversation over.

That didn't work so well for Dragonfly, did it?

Yoav