Re: [Cfrg] Task looming over the CFRG

[Paul Lambert <[e-mail]>]

Hi Rene,

From: Rene Struik <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 5, 2014 at 11:35 AM
To: "Igoe, Kevin M." <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Cfrg] Task looming over the CFRG

Hi Kevin:

Just a few hours prior to the CFRG Interim, David McGrew suggested some criteria for elliptic curves, on which a few comments were received on the mailing list. This list was also - very briefly - discussed during the Virtual Interim. During the virtual interim, there were presentations by various people on curve picks. There was no discussion on schemes these curves should be used with (except for plain ECDH).

I think it would be premature to now already draw a conclusion here,

I disagree.  The consensus in the ad hoc was clear.  Discussions on this list are consist with the ad hoc discussion.   The flurry of activity in other working groups also reflects the same consensus to recommend Curve25519.

since there has hardly been time to digest presentations and reflect upon this.

True, but none of the items were new information. Anyone participating in an informed discussion should be familiar will all of the criteria. The collection of the list is valuable and could be the basis of any final formal recommendation.  Expressing the criteria in neutral and fair language that captures the background and importance of each requirement is worthy of it’s own additional effort … but should not delay decisions we make based on our discussions.

We can move forward with a recommendation and continue to use David’s excellent list as the benchmark for rational of the selection.

There was also additional work we need to consider and the ad hoc ran out of time to summarize work items.  Specifically, there are supporting recommendations required to:
 - document the changes in ECDH for cofactors >1
    - this may impact a variety of specifications.

I’m also not clear yet what is the recommendation for digital signatures.   At a minimum, recommendations should be established to make ECDSA deterministic.   Other signature algorithms are possible, but the impact on PKI or alternatives of introducing a new signature algorithm needs some discussion (IMHO).

 I’d like to see a self consistent recommendations that define  key exchanges and signatures for the same curve (or related transformed curve).  PKI interworking to bridge to the new curves would fall out from this set of definitions.

Paul


Any presumed concensus by attendees during the call could hardly have been based on reflecting on presented material, since this was uploaded x-minutes prior to the meeting and there was no magical break during the interim to digest material further. So, what was the point of the curve selection criteria strawman and virtual interim presentations if the conclusions are already known now?

I would suspect (and raised this on the chat box at the end of the interim) that there should be a sequel to this during the IETF-90 meeting in Toronto (assuming CFRG would indeed meet there).

Best regards, Rene

http://www.ietf.org/mail-archive/web/cfrg/current/msg04461.html

On 5/5/2014 1:58 PM, Igoe, Kevin M. wrote:
As most the folks who read this list have noticed, a virtual interim meeting of the CFRG
was held on Tues 29 April to discuss the way forward for elliptic curve cryptography
in the IETF.  This was driven by an earnest plea from the TLS WG for firmguidance from
the CGRG on the selection of elliptic curves for use in TLS.  They need an answer before
the Toronto IETF meeting inlate July.  TLS needs curves for several levels of security (128,
192 and 256), suitable for use in both key agreement and in digital signatures.


 *   The consensus of the attendees was that it would be best for TLS to have a single
“mandatory to implement” curve for each of the three security levels.



 *   Though the attendees were reluctant to make a formal commitment, there
was clearly a great deal of support for the Montgomery curve curve25519 (FYI, the
25519 refers to the fact that arithmetic is done modulo the prime 2**255 – 19 ).



 *   curve25519 only fills one of the three required security levels.  We still need
curves of size near 384 bits and 512 bits.



 *   NIST curves: I doubt TLS will be willing to revisit the question of elliptic curves once the
CFRG has made their recommendation.  Another option to consider is advising TLS to
use of the NIST curves in the short term, buying time for the CFRG to do an unrushed
exploration of the alternatives, drawing academia and other standards bodies into the
discussion.


P.S.  It has been suggested that the CFRG hold a session at the Crypto conference in
Santa Barbara in an effort to draw in more participation from the academic community.
No guarantees we can pull this off, but it is worth the attempt. Thoughts? Volunteers?

P.P.S. We need to start lining up speakers for the CFRG session at IETF-90 (Toronto).


----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
[e-mail]<mailto:[e-mail]>  | of thinking we used when we created them."
                |              - Albert Einstein -
----------------+--------------------------------------------------






_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>http://www.irtf.org/mailman/listinfo/cfrg



--
email: [e-mail]<mailto:[e-mail]> | Skype: rstruik
cell: [phone] | US: [phone]