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

On Sat, Jan 11, 2014 at 8:32 AM, Simon Josefsson <simon@josefsson.org> 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.

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

>
> 2) Does description of private/public key representation and computation
>    of shared secret belong in draft-josefsson-tls-curve25519?  It has to
>    be somewhere, I believ, but possibly this could go into
>    draft-ladd-safecurves, or some other generic document, unless there
>    are TLS-specific aspects.  Insight into this would be appreciated.

It looks good, but the specification should ideally be in the draft or
cited in an informative RFC. draft-ladd aims to completely
specify what is exchanged, and so is a better (IMHO) source for the
normative part then the curve25519 paper.
Worst case you can write something close to the specification section
of "Cryptography in NaCl" or "Curve25519:
New Diffie-Hellman Speed Records" in the case draft-ladd fails to progress.

Sincerely,
Watson Ladd
>
> Cheers,
> /Simon
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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