[Cfrg] Curve selection revisited

[Benjamin Black <[e-mail]>]

Inspired by some comments from other and in hopes of returning to a more
productive debate rather than the pointed back and forth, of which I am
absolutely guilty, I'm suggesting a few constraints. These are not priority
ordered and none of them deal with the math, instead focusing on process
and practice.

1) As we are discussing this in the context of TLS, the performance of
various kx options must be evaluated for ECDHE as typically deployed. ECDH
is neither common nor recommended in the TLS BCP draft. In addition, I hope
there will be discussion of benchmarking methodology, with the
understanding the ultimate choice is for the CFRG chairs.

2) Performance must be measured using "production-quality" implementations.
By this I mean implementations which employ the sort of
techniques/optimizations appropriate for large scale deployment. This is
specifically intended to exclude discussion of how simple or fast an
implementation _could_ be, in favor of what they actually are in practice.
However, the goal is to select curves which strike the best balance between
various requirements, not simply the fastest.

3) The timeframe for a decision constrains the scope of this process. If a
decision is desired within a few months, then it is difficult to include
options beyond new curves. If a decision can take a year, new algorithms
could be considered. Given the importance, impact, and contentiousness of
new algorithms, I believe it would be difficult to complete a thorough,
careful algorithm and curve selection process in a short amount of time.

4) The precise set of security levels needed should be specified in advance
(whether by TLS or CFRG) and curve recommendations delivered together for
all levels. A stated goal is to use these curves in new drafts, and it
minimizes work to specify all security levels for a proposal in the same
draft. This is strictly a practical matter recognizing the chairs and area
directors have limited bandwidth and implementors can get everything done
in a single go.

5) Selections must efficiently support TLS 1.2. Adoption of new curves, and
potentially new algorithms, can't be gated on completion and widespread
deployment of TLS 1.3.

6) Drop-in replacement for the NIST curves is _not_ a requirement in this
process.

7) I don't think the chairs are signing up for a full-on, NIST-style
selection competition and we should aim to keep things are lightweight as
possible while still achieving the required level of rigor. I hope they
will address this point soon.


Ben