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

From: [email-masked]
Date: Fri, 22 Jan 2016 16:27:10 -0800 (PST)

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:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 24 Jan 2016 08:47:24 +0000

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.

Lars

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 24 Jan 2016 11:26:34 +0000

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.

S

>> Title:      Elliptic Curves for Security Author:     A. Langley, M.
>> Hamburg, S. Turner Status:     Informational Stream:     IRTF Date:
>> January 2016 Mailbox:    [email-masked], [email-masked], 
>> [email-masked] Pages:      22 Characters: 39298 
>> 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.
>> 
>> 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 
>> 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 [email-masked].
>> 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 
> [email-masked] https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 25 Jan 2016 08:01:22 -0800

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

> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 25 Jan 2016 17:05:40 +0000

> some 5-6 years after everyone realized how simple it is to write crypto code
> when you actually care about making it simple.

I think this timeline is incorrect.  Let's think about the little more than a year, since the IETF first took up this work.  Nobody stopped anyone from adopting it before, like you point out with OpenSSH, but it's a big difference for adopting it within things like TLS and implementations of that.

> Let's Encrypt has had far more of an impact

Apples and oranges.

> Blake2 didn't have to go through anything like this. Nor did Camelia, nor the
> various national elliptic curve standards.

I am reasonably happy with the pace of crypto progress in the IETF.  Having a barrier to national standards national standards on the general International Internet is not necessarily a bad thing.  Especially when interacting with "pay for play" standards organizations.

> let's not be self-congratulatory about our impact, which in this case has been
> extremely negative.

I respectfully disagree.

---

From: Bill Cox <[email-masked]>
Date: Mon, 25 Jan 2016 09:24:02 -0800

> which in this case has been extremely negative.

I think a lot of us observers like me have found this effort very helpful.
CFRG has credibility which is lacking at NIST, so a lot of geeks like me
are looking to CFRG for guidance.  I have already found that getting devs
to support Ed25519 is simpler now that it is essentially blessed by CFRG.

I am advocating for supporting BLAKE2 in OpenSSL
<https://github.com/openssl/openssl/pull/566> (thanks go to Rich Salz for
his help on this).  This will have a substantial security benefit to the
world, IMO, since more people will be willing to switch from MD5/SHA1 to
something we believe to be more secure like BLAKE2, sim[ply because it is
faster.  I can say exactly the same thing for Ed25519.

I assume this has already been considered, but if CFRG were willing to take
a position on BLAKE2, I think that could accelerate adoption.  I am also a
fan of Keccak, and I use both, but in most of my applications, BLAKE2 is
more appropriate.  I see a lot of users switching to Keccak when BLAKE2
would server them better.  The CFRG seems to be in a position to help the
world make better choices.

Thanks,
Bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Jan 2016 13:43:35 -0500

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.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 25 Jan 2016 11:05:48 -0800

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

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

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 25 Jan 2016 12:32:25 -0800

On Monday, January 25, 2016, Watson Ladd <[email-masked]> wrote:

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

I largely agree with what you're saying, but people seem excited about this
(although perhaps given this RFC's informational status, the wording here
is misleading):

https://twitter.com/bascule/status/690708191747842049

If there's something to be excited about here, I think it's that future
IETF protocols now have something to look to which isn't produced by the
standards body of a single nation (e.g. NIST) but something of an Internet
standard. As you noted this has already been happening in a grassroots way
so perhaps the publishing of this RFC won't be particularly impactful on
actual engineering practice...

If there's one thing I hope this affects, it's NIST's selection of next
generation elliptic curves. At a time when they're trying to restore trust,
it would look rather odd if they didn't standardize the CFRG curves.

-- 
Tony Arcieri

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 25 Jan 2016 20:35:53 +0000

> I don't know that anyone who wasn't planning on supporting Curve25519 before this

A more accurate question is "is anyone going to do X25519 now who was waiting before this?"  And there answer there is a resounding yes.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 25 Jan 2016 15:55:03 -0500

> A more accurate question is "is anyone going to do X25519 now who was waiting before this?"  And there answer there is a resounding yes.

I work with highly constrained sensors where Curve25519 is an important 
step forward.  One vendor implemented it without any need of an IETF 
standard (even informational).  But then their tech is a bit different.  
But in IEEE 802 land, we need standards to reference.  So to get 
Curve25519 included, it is either put it into the IEEE document 
directly, or reference some other standards organization's standards.  
Thus this is a big step forward.  Next will be an Ed25519 document.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Jan 2016 17:05:33 -0500

> A more accurate question is "is anyone going to do X25519 now who was waiting before this?"  And there answer there is a resounding yes.

More importantly, I have a few customers for EC certs today but not a
huge number. I expect that the CFRG process will make Curve 448 the
default.

Curve 25519 is a bit of a non issue since there really isn't an
argument to use it in the WebPKI right now. And there won't be a
reason to use it with TLS unless the botched construction of the
ephemeral key is fixed.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 25 Jan 2016 14:07:45 -0800

before this
>>> discussion is going to introduce it now over their own prefered
alternative
>>
>> A more accurate question is "is anyone going to do X25519 now who was
waiting before this?"  And there answer there is a resounding yes.
step forward.  One vendor implemented it without any need of an IETF
standard (even informational).  But then their tech is a bit different.
But in IEEE 802 land, we need standards to reference.  So to get Curve25519
included, it is either put it into the IEEE document directly, or reference
some other standards organization's standards.  Thus this is a big step
forward.  Next will be an Ed25519 document.

And that step (publication of an RFC) could have been accomplished in a
much easier way, either through the independent stream or through the CFRG
without the "contest".

Furthermore the security gains of taking a generic Weierstrass
implementation and modifying it to work with Curve25519 are minimal. The
real security gains come from using a function from 32 bytes cross 32 bytes
to 32 bytes: everyone can understand that, and there is only one mistake
you could possibly make.

We need to see the work that UTA did as far more useful to security,
because it is. People are now aware of the problems in TLS and how to avoid
them. RFC 7748 doesn't do the same thing for ECC.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 25 Jan 2016 22:09:10 +0000

> And that step (publication of an RFC) could have been accomplished in a much easier way, either through the independent stream or through the CFRG without the "contest".

But the CFRG was asked by TLS to basically hold such a contest.  Because they wanted something that had some review.

So the system worked. :)

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Jan 2016 00:34:00 +0200

> On 25 Jan 2016, at 10:32 PM, Tony Arcieri <[email-masked]> wrote:
> 
> On Monday, January 25, 2016, Watson Ladd <[email-masked] <mailto:[email-masked]>> wrote:
> I largely agree with what you're saying, but people seem excited about this (although perhaps given this RFC's informational status, the wording here is misleading):
> 
> https://twitter.com/bascule/status/690708191747842049 <https://twitter.com/bascule/status/690708191747842049>

At least it’s inaccurate IETF jargon.

Both TLS and IPsecME have been waiting for this. With this RFC published, those drafts are a foregone conclusion. The TLS one might wait for the signatures document, but the IPsec one doesn’t even have to do that.

> If there's something to be excited about here, I think it's that future IETF protocols now have something to look to which isn't produced by the standards body of a single nation (e.g. NIST) but something of an Internet standard.

I haven’t checked all 7700+ RFCs, but ISTM that the IETF and IRTF are for the first time pushing algorithms into the mainstream (where they are MUSTs and SHOULDs for major protocols) that did not come through NIST. It started with ChaCha20/Poly1305, now this and soon the Edwards curves. In a sense, CFRG is filling in here for NIST, by choosing, recommending and documenting cryptographic primitives. That’s a pretty big deal IMO.

> As you noted this has already been happening in a grassroots way so perhaps the publishing of this RFC won't be particularly impactful on actual engineering practice…

I think the process that made this RFC is important in getting these algorithms from local experiments and small projects to the browsers and servers and VPN gateways used everywhere. 

> If there's one thing I hope this affects, it's NIST's selection of next generation elliptic curves. At a time when they're trying to restore trust, it would look rather odd if they didn't standardize the CFRG curves.

And Edwards signatures and ChaCha20/Poly1305. It’s silly if people had to disable all those in order to be “FIPS compliant”

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Jan 2016 00:38:07 +0200

> On 26 Jan 2016, at 12:09 AM, Salz, Rich <[email-masked]> wrote:
> 

To be fair, TLS just asked for a curve. Maybe two. They did not specify how these were supposed to be obtained. In fact, I’m pretty sure they would have been happy if this were sooner.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Jan 2016 23:02:30 +0000

I don't recall this bit of history being on this list
(recently anyway) so apologies to those who've heard
it before...

On 25/01/16 20:32, Tony Arcieri wrote:
> given this RFC's informational status

The IETF has traditionally used informational RFCs to
document cryptographic algorithms. The logic for that
is that the IETF doesn't invent algorithms so in most
cases the RFCs were just copies/translations of other
documents, whether from other standards organisations
or elsewhere. I'm not sure what's the earliest case of
us having done that but maybe it was RFC1186 in 1990?
So this has been done for 25 years anyway.

Anyway this is entirely in keeping with that. So this
being an informational RFC is exactly right.

Cheers,
S.

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 25 Jan 2016 17:39:59 -0800

> being an informational RFC is exactly right.

Not disagreeing with that, but several people dinged my tweet on using the
word "standard" to refer to RFC 7748 despite it being an informational RFC.
I'm the first to agree my IETF-ese is poor and I just wanted to point that
out in advance lest someone bring the same thing up here.

-- 
Tony Arcieri

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Jan 2016 21:47:02 -0500

I am not sure the precedent should continue to apply.

Back when we did MD5 and so on, the process was Ron wrote the draft,
it was published, we used it. So Informational was quite appropriate.
There was review but none of it was in IETF.

This time we did do a review and a pretty extensive one. In fact
probably one of the most extensive reviews that has taken place on ECC
technology. It would not be unreasonable to upgrade it to Standard.

More structurally, IRTF has slipped into the role that NIST used to
occupy here.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 25 Jan 2016 21:32:14 -0800

> There was review but none of it was in IETF.

Actually there was almost no review. MD5 was too weak from day one (256
times stronger then DES), and by 1996 was dead. Any halfway competent
review would have caught both these issues, but it wasn't until 2004 that
MD5 got eliminated.

Oh wait that didn't happen. In 2007 Alex Sotirov, Marc Stevens, and a
number of others forged a intermediate cert. Thankfully they didn't quietly
sell that to the Russian mafia, who could have afforded it. We're just
meeting the SHA-1 deadline, but an unknown, possibly large number of
systems are still vulnerable.

The sort of review I'd like to see CFRG do is one focused on understanding
the security properties of protocols, that is quick and reliable enough
that we end the cottage industry of attack papers at RWC and crypto
exploits at Blackhat. The process leading to X25519 should not be a model
for what CFRG is supposed to do. It's clear that we need more review. But
what we don't need is a process that takes 2 years every time, and doesn't
limit itself to security.

> More structurally, IRTF has slipped into the role that NIST used to

NIST never mandated RSA, but prefered DSA+DH constructions for patent
reasons. RSA was prefered by industry including finance. NIST was almost
completely reliant on the NSA for expertise, and that's only slowly
changing. MD5 and RC4 were never NIST approved. Rumors of NIST controlling
crypto are greatly exaggerated.

---

From: [email-masked]
Date: Tue, 26 Jan 2016 09:41:19 +0000

> I am not sure the precedent should continue to apply.

It's good enough and changing would be pointless pain.
 
> More structurally, IRTF has slipped into the role that NIST used to

Not slipped, no. IMO a working CFRG, like we have now, has a slightly  different role (open, not one country) and gets us more direct  involvement from  crypto folks. NIST input is still welcome too though of course. But this was mentioned as being the plan as far back as ietf88 iirc. 

S.