Re: [Cfrg] Task looming over the CFRG

[Paul Lambert <[e-mail]>]

From: Rene Struik <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 5, 2014 at 12:28 PM
To: Paul Lambert <[e-mail]<mailto:[e-mail]>>, "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 Paul:

I do not think there is reason to mute technical discussion,
No such intent … just an observation that you hold a minority view point.

On your advocacy … are you proposing that the NIST curves be maintained as the primary recommendation, or do you have other preferences in your curves?

esp. since the criteria David McGrew put forward were just a strawman proposal and seemed to pre-sort solution directions (see, e.g., Mike Hamburg's response Wed last week, April 30th) and did not receive technical feedback before.

Yes … the criteria could be tuned to be more neutral and to have a ranking of importance.  Additional criteria could also be added to make NIST curves more favorable if we are simply creating a score card.  However, I’m not sure the consensus would change.

NIST curves were created over 15 years ago.  NIST has not kept pace in this period with recommendations to mitigate attacks documented by industry.  NIST has not considered the advancements in open cryptographic publications that have identified new curves and algorithms that provide improved performance and better “safety” of implementations.  Patents have expired since the publication of the original NIST recommendations that open new opportunities for license-free security based on elliptic curves.

This emphasizes that there may be different perspectives on what would be appropriate criteria ("the" criteria as you were paraphrasing was simply a set of potential criteria put forward).

Yes.  Like statistics, criteria can be abused to justify a particular result.  I do not see that that was the intent of the list published to this working group.   If you see ways that the criteria could be modified or extended to sway the group to your preferred curve choice, please do be specific and provide a compelling analysis.

FYI - You suggested that "At a minimum, recommendations should be established to make ECDSA deterministic". You may wish to have a look at RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (August 2013).6979.

Yes, I am very familiar with RFC 6979. This is an informational RFC and provides the procedures and test vectors for “Deterministic ECDSA”.  It is not a “recommendation” or requirement.  This is not a black box testable recommendation since you can not easily tell a truly random the use in ECDSA of: a truly random number, a deterministic number, a back-door predictable deterministic number, etc.   This is an area that NIST has completely failed industry.   Attacks and mistakes in implementations are possible with the NIST ECDSA recommendations.  RFC 6979 helps and “deterministic” techniques should be more strongly codified as a recommendation.


Paul



Best regards, Rene

[excerpt of your email of May 5, 2014, 3:09pm EDT]
True, but none of the items were new information. Anyone participating in an informed discussion should be familiar will all of the criteria.

On 5/5/2014 3:09 PM, Paul Lambert wrote:

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 severallevels 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]





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