Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves

[Watson Ladd <[e-mail]>]

On Tue, Jul 15, 2014 at 2:51 AM, Johannes Merkle
<[e-mail]> wrote:
> Watson Ladd wrote on 15.07.2014 03:11:
>>>
>>> Interoperability
>>>
>>>    R6.  Desired: can be used with current software implementations
>>>    (using different curve parameters) of TLS, PKIX, SSH, and IKE [4]
>>>
>>>    R7.  Desired: can be used within current ECC standards of TLS,
>>>    PKIX, SSH, and IKE [4]
>>
>> These desiderata are worthwhile, but implementors have signalled they
>> are willing to make
>> large changes for performance.
>>
>
> Well, I'm not so sure. On the TLS mailing list, there have been some messages expressing the opposite opinion.
> https://www.ietf.org/mail-archive/web/tls/current/msg12960.html
> http://www.ietf.org/mail-archive/web/tls/current/msg12975.html
> https://www.ietf.org/mail-archive/web/tls/current/msg12320.html
> http://www.ietf.org/mail-archive/web/tls/current/msg12983.html
>
> Actually, you have responded to most of these, but this does not necessarily eliminate the objections.

Since we aren't replacing the NIST curves its fine if some, even a lot
of, people don't want to use them. Not everyone uses
Camelia or AES after all.

By contrast, the interest in Curve25519 comes from the speed: no one
wants or uses Brainpool because it is slow.
(The fact that we already have a set of alternative curves with
nothing to recommend them beyond alternative generation is frequently
forgotten in these arguments). If we sacrifice speed in favor of
Weierstrass form, I'm not going to be very happy:

1: We asked about using something very fast
2: There were no security objections
3: The IETF happened
4: We got something slow, out of deference to people who won't use it anyway.

Now, for GLV curves there may be patent issues, and for
hyper-and-elliptic (use hyperelliptic curves for variable base,
elliptic curves for fixed base with deep cleverness to interconvert)
the complexity might not be worth the added speed. It's not that
simplicity isn't important, but that the range of performance vs.
complexity tradeoffs tends to strongly favor speed in this domain.

(One interesting counterexample is Bitcoin: the CM is not used despite
the curve being designed for it)

Sincerely,
Watson Ladd