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

[Watson Ladd <[e-mail]>]

On Mon, Jan 25, 2016 at 10:43 AM, Phillip Hallam-Baker
<[e-mail]> wrote:
> 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.

Actually the security issues caused by the incomplete addition
formulas have been very well known for years. Really what this reveals
is how little people care about "actual security", that is the
exploits and weaknesses in existing deployed code and standards, and
how much people care about "imagined security", the risks of
subverting standards with tools we don't even know how would work.
Why? Because you need to have some taste and knowledge to care about
actual security, but every child can understand the tale of the bad
vizir.

Remember, the NSA is actively exploiting IKEv1 PSK aggressive mode.
Everyone I've talked to about this is completely unsurprised: they
knew about the hole since the day the RFC was published. Likewise
complaints about the OpenSSL API and the difficulty of encrypting
securely have been around since the beginning, but it wasn't until
Nacl that people tried to do something about it.

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

Exactly right. The IETF took what, if ordinary standards of "running
code and rough consensus" were applied, would have been a short
process, and decided to run a contest, effectively paralyzing the CFRG
for two years. Part of the reason was that it would avoid
fragmentation, but instead Microsoft is asking NIST to standardize its
variants, and same with the Brainpool people. Now we're taking
tcpcrypt, and again for political reasons, turning what would be a
simple "here is what you do to run this cool thing" into a baroque
construction that will be far harder to use. Then again this is
largely the story of IKEv2 vs. JFK, and IPsec more generally.

>
> 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 <[e-mail]> wrote:
>> On Sun, Jan 24, 2016 at 3:26 AM, Stephen Farrell
>> <[e-mail]> 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, [e-mail] 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:    [e-mail], [e-mail],
>>>>> [e-mail] 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 [e-mail].
>>>>> 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
>>>> [e-mail] https://www.irtf.org/mailman/listinfo/cfrg
>>>>
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>
>>
>>
>> --
>> "Man is born free, but everywhere he is in chains".
>> --Rousseau.
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.