Re: [Cfrg] RFC 7748 on Elliptic Curves for Security

I disagree.

The timeline in question began on Friday September 6th 2013. That was
the day that Glenn Greenwald revealed the existence of BULLRUN and the
attempts to sabotage open standards for crypto. It is a little over
two years since the initial discovery of the breach.

Until that point there was no reason to call into question the NSA
curves. And it was some time later that the DUAL_EC_RNG attack was
discovered. And it took people some time to decide on what the
appropriate response to the curve situation was.

The other bit of history here is that people have been peddling ECC
curves for almost 20 years without much interest in the broader
industry. The field has been clouded by purported IP claims that have
effectively poisoned the well for proposals.

Nor was it the case that Curve 25519 was a slam dunk proposition.
There was a very good argument for going with the completely rigid
curves proposed by Brian and his team. The CFRG was not asked to
standardize Curve 25519. On the contrary it was tasked with performing
a survey of options and picking one.

Congratulations to everyone involved and thanks for the work on what I
believe will become one of the key building blocks for future
cryptographic infrastructures.

On Mon, Jan 25, 2016 at 11:01 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Sun, Jan 24, 2016 at 3:26 AM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>> On 24/01/16 08:47, Eggert, Lars wrote:
>>> Excellent work, all! This is one of the more important RFCs that the
>>> IRTF has published, and will have a direct impact on Internet user
>>> privacy.
>>
>> Indeed. Good work and thanks to all including those whose fav
>> curves didn't end up being part of the RFC - the debate, hard
>> and gnarly though it was, was also an important part of this.
>
> Really?
>
> This RFC comes some 10 years after the introduction of Curve25519, and
> some 5-6 years after everyone realized how simple it is to write
> crypto code when you actually care about making it simple. The
> existence of tools like signify and minilock was thankfully not
> dependent on our blessing, which in any case, because the result is
> Informational, apparently doesn't exist. (Nor for that matter was the
> adoption in OpenSSH dependent, etc., etc.)
>
> The process hasn't lead to increased support from industry, in fact
> the same players are now battling it out at NIST instead. I don't know
> that anyone who wasn't planning on supporting Curve25519 before this
> discussion is going to introduce it now over their own prefered
> alternative, or that it even matters for "Internet user privacy".
> Let's Encrypt has had far more of an impact, by ending an ill-thought
> out experiment in charging people money to secure their websites. The
> various attacks enabled by the bugs in implementations in the NIST
> curves generally require some precise targeting: they are not "let's
> decrypt all the data on the Internet".
>
> Blake2 didn't have to go through anything like this. Nor did Camelia,
> nor the various national elliptic curve standards. I'm glad we are
> done with this, but let's not be self-congratulatory about our impact,
> which in this case has been extremely negative.
>
>>
>> S
>>
>>>
>>> Lars
>>>
>>> On 2016-01-23, at 1:27, rfc-editor@rfc-editor.org wrote:
>>>>
>>>> A new Request for Comments is now available in online RFC
>>>> libraries.
>>>>
>>>>
>>>> RFC 7748
>>>>
>>>> Title:      Elliptic Curves for Security Author:     A. Langley, M.
>>>> Hamburg, S. Turner Status:     Informational Stream:     IRTF Date:
>>>> January 2016 Mailbox:    agl@google.com, mike@shiftleft.org,
>>>> sean@sn3rd.com Pages:      22 Characters: 39298
>>>> Updates/Obsoletes/SeeAlso:   None
>>>>
>>>> I-D Tag:    draft-irtf-cfrg-curves-11.txt
>>>>
>>>> URL:        https://www.rfc-editor.org/info/rfc7748
>>>>
>>>> DOI:        http://dx.doi.org/10.17487/RFC7748
>>>>
>>>> This memo specifies two elliptic curves over prime fields that
>>>> offer a high level of practical security in cryptographic
>>>> applications, including Transport Layer Security (TLS).  These
>>>> curves are intended to operate at the ~128-bit and ~224-bit
>>>> security level, respectively, and are generated deterministically
>>>> based on a list of required properties.
>>>>
>>>> This document is a product of the Crypto Forum Research Group of
>>>> the IRTF.
>>>>
>>>>
>>>> INFORMATIONAL: This memo provides information for the Internet
>>>> community. It does not specify an Internet standard of any kind.
>>>> Distribution of this memo is unlimited.
>>>>
>>>> This announcement is sent to the IETF-Announce, rfc-dist and
>>>> IRTF-Announce lists.To subscribe or unsubscribe, see
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>> https://www.irtf.org/mailman/listinfo/irtf-announce
>>>>
>>>> For searching the RFC series, see
>>>> https://www.rfc-editor.org/search For downloading RFCs, see
>>>> https://www.rfc-editor.org/rfc.html
>>>>
>>>> Requests for special distribution should be addressed to either
>>>> the author of the RFC in question, or to rfc-editor@rfc-editor.org.
>>>> Unless specifically noted otherwise on the RFC itself, all RFCs are
>>>> for unlimited distribution.
>>>>
>>>>
>>>> The RFC Editor Team Association Management Solutions, LLC
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________ Cfrg mailing list
>>> Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg