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

[Watson Ladd <[e-mail]>]

On Sun, Jan 12, 2014 at 11:27 PM, Yoav Nir <[e-mail]> wrote:
>
> 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?

The huge difference between these curves and Dragonfly is that these
curves satisfy every known property required to make ECDH secure, and
also some designed to make implementation easier. Dragonfly had
obvious security flaws.

If you want more of a process, go ahead and start it. But I think what
you will get is a bunch of "Yes, these numbers are prime"
and "I clicked all the links on safecurves.cr.yp.to and used PARI to
verify everything". If they are missing attacks, that's one thing,
but they aren't.

Security conversations are never over: it's entirely possible that
tomorrow a paper hits IACR which identifies a new set of
weaknesses in elliptic curves, and then we have to go through and see
which ones fall.

Sincerely,
Watson Ladd
>
> Yoav
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin