Re: [Cfrg] Curve selection revisited

["Paterson, Kenny" <[e-mail]>]

Ben

Thanks for this helpful message. I've responded in-line below,
representing the chairs and based on what I've heard on the list and at
the IETF meeting this week. People on the list should still feel free, of
course, to argue for other points of view.

On 25/07/2014 01:10, "Benjamin Black" <[e-mail]> wrote:

>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.

Some detail on benchmarking methods will indeed be helpful.

My perspective, from having talked to a number of vendors this week, is
that speed (one measure of performance) is important, but being the
fastest is not if the performance difference is x%. Here x is a variable
that ranges somewhere between 5 and 50 depending on which vendor you talk
to.

>
>
>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.
>

I don't think it's very easy to be concrete about what
"production-quality" means. I tend to agree with Yoav's comments here
(http://www.ietf.org/mail-archive/web/cfrg/current/msg04735.html).

>
>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.
>

Yes, I agree. 

Our process is not going to be perfect. We don't have the resources of
NIST/NSA/your favourite agency here. This is not the AES or SHA-3
competition. Yet we can draw on many years of ECC experience and expertise
of people on the list (and off it).

I had a strong steer this week from the TLS WG chairs and other people
active in the TLS WG that ECDHE and EC-DSA are the target algorithms for
us to think about when selecting curves. In other words, it's about new
curves for existing algorithms, not new curves AND new algorithms. That
does not preclude the introduction of new algorithms via CFRG over a
longer timescale, but it's not part of our current work.


>
>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.
>

This is not a point of contention. We've been asked by the TLS WG to
produce curves at the 128-bit and 256-bit levels, with a 192-bit option if
we wish. 

There is some wiggle room here - for example, a suitable curve with small
co-factor defined over a prime with 383 bits would be acceptable as
meeting the 192-bit level, etc.

>
>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.

I don't see TLS 1.3 as being an issue. We can safely assume it is going to
be using the same basic algorithms as TLS 1.2 ECC.

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

I agree. At Toronto, the common view amongst people I talked to was that
"Weierstrass-only" form curves (i.e. curves of prime order) is not a
*hard* requirement.

The benefits of switching to other curve forms (speed, simplicity of
side-channel protection) may well outweigh the benefits of sticking with
W-only forms (code re-use, familiarity for developers, no co-factor to
worry about).

>
>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.
>

I'm not sure in what way you'd like the chairs to address this point. I
hope it was clear from the initial announcement
(http://www.ietf.org/mail-archive/web/cfrg/current/msg04655.html) that
we're running a lightweight process lasting a couple of months.

That has not changed.

Best regards,

Kenny

>
>
>
>Ben
>