[Cfrg] Notes on curve selection from IETF90

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

Hi,

At IETF90, CFRG was asked to report back to the TLS WG on progress on
curve selection. I prepared and presented some slides which in theory you
should be able to find online here:

https://datatracker.ietf.org/meeting/90/agenda/tls-drafts.pdf


But that pdf seems to be empty right now. So I thought it would be useful
to re-present some of the slides here in text format, as a snapshot of
where I think we are in the process and discussion on requirements. Note
that the views represented here are those of chairs and are based on
discussions on the list and discussions at the meeting here in Toronto.

Comments welcome.

Cheers,

Kenny

---

CFRG@IETF90

­Wednesday 1300-1500
­Roughly 90 minutes presentation + discussion on new ECC.
­Overview talk on ECC old and new from Tanja Lange (TU Eindhoven).
­Talk on NUMS curves from Brian LaMacchia and Craig Costello (Microsoft).
­Talk on Curve25519 and friends from Dan Bernstein (UIC/TU Eindhoven).
­Lively Q&A/discussion, continued at ISRG dinner.



Emerging Areas of Consensus on Requirements


-Protection against side-channel attacks strongly desired.

-Basic elements of curve selection ­ defined over prime field; prime or
near-prime
order; twist security.
­-Not always needed, but we can achieve these at no real cost.

-Need to support existing algorithms.
­-Strong steer from TLS WG.
­-ECDHE, EC-DSA, and maybe ECDH.
­-Interop with existing wire formats desirable, not essential.
­-Versus potential perf. gains from adopting new algs

-Need for rigidity in curve generation process.
­-Trustable curve generation process is important.
­-It¹s a primary motivation for this work.
­-How much rigidity is enough to satisfy public opinion?


Emerging Areas of Consensus on Curve Form


-Switch from Weierstrass-only form to alternative forms
(Montgomery/Edwards/twisted Edwards)
­-Deployability of new W.-only form curves not significantly easier, even
though there¹s a large deployed code base for W.-only form curves.
­-Much easier side-channel protection without perf. sacrifice using alt.
forms.
­-Co-factor > 1 for alt. forms has potential for implementation errors.
­-Overall, tenatively, alt. forms seem to be the way to go.

-Growing realisation amongst non-experts.
­-It¹s complicated!




Current Areas of Debate


-Specific implementation detail at 128-bit security level:
­-(Montgomery + twisted Edwards for ECDHE + point conversions) versus just
twisted Edwards for ECDHE?
­-Related implications for wire format.

-What does ephemeral mean?
­-Server-side: every key exchange or every 10s or every hour?
­-Has implications for selection of curve form (costs of fixed base versus
variable
base computations).

-Actual choice of specific curves.



Summary (personal view)

-In terms of perf+security, there¹s not much to choose between the
competing alt. (i.e. non-W.-only) curve proposals at each security level.

-We¹re making progress; rough consensus on requirements should be possible.

-Getting consensus on selection of curves will require some give and take
from competing proposers.