Re: [Cfrg] Task looming over the CFRG

[Rene Struik <[e-mail]>]

Hi Paul:

I do not think there is reason to mute technical discussion, 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. 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).

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

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 firm/**/guidance /**/from
>>     the CGRG /**/on the selection of elliptic curves/**//**/for use
>>     in TLS.  They need an answer /**/before
>>     /**/the /**/Toronto/**/IETF meeting i/**/n/**/late 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] | of thinking we used when we created them."
>>     |              - Albert Einstein -
>>     ----------------+--------------------------------------------------
>>
>>
>>     _______________________________________________
>>     Cfrg mailing list
>>     [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>
>
>     -- 
>     email:[e-mail]  | Skype: rstruik
>     cell: [phone] | US: [phone]
>
>
>


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