Subject: Re: [Cfrg] My comments on TLS requirements from today's interim

From: Andrey Jivsov <[email-masked]>
Date: Tue, 01 Jul 2014 00:03:48 -0700

I have the same concern:

On 04/29/2014 12:50 PM, Eric Rescorla wrote:
>
> - It would be nice if there was some chance that these curves could
>    have some chance of being FIPS-approved, so they could potentially
>    displace the NIST curves. It may be very difficult to get certainty here.

I see the following (the meeting minutes) 
http://www.ietf.org/mail-archive/web/cfrg/current/msg04505.html that 
don't answer this.

I also saw this post:
On 06/26/2014 11:46 PM, Alyssa Rowan wrote:
 > CFRG have selected Curve25519 as the preferred elliptic curve for use
 > in IETF protocols, as Rich has pointed out.

Let's assume that "the curve" at IETF is Curve25519. It doesn't appear 
to be an undisputed winner right now, but let's assume that it is 
universally accepted at every working group at IETF and is added to 
every IETF protocol soon.

There is a significant US federal market with Suite B, FIPS, or at least 
SP 800 XXX that in some cases supports multiple product lines for a 
company. Beyond that, one credit that Suite B gets is that Suite B 
provided a clear and safe path for anybody who wanted to add ECC to 
their products. It assured interoperability on the Internet and coverage 
for the US government sector in a single standard. It made it much safer 
to create persistent data structures that should exist for decades. Not 
everybody liked it, especially outside of US, but P-256 was and still a 
method to bootstrap into ECC.

I would like to hear your thoughts on the long-term view regarding 
standardization.

I will start with a few possibilities:

* Curve25519 becomes so pervasive that NIST adopts it. It replaces P-256 
as a standard [Should reaching out to NIST be on the roadmap at some 
point before that expected acceptance?]

* Curve25519 exists parallel to P-256 (and P-256 becomes just a US 
national standard) [In this case products accept that Curve25519 + all 
the national standards is a typical product requirement]

* Curve25519 is viewed as a couple-of-years forward solution and so the 
questions of integration with other standards is out of scope for the 
Curve25519 decision [perhaps because the focus is on currently common 
Intel x86 CPUs, ARMs?]

<other possibilities, I am sure>...

Thank you.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Jul 2014 10:28:23 +0300

On Jul 1, 2014, at 10:03 AM, Andrey Jivsov <[email-masked]> wrote:

> I see the following (the meeting minutes) http://www.ietf.org/mail-archive/web/cfrg/current/msg04505.html that don't answer this.
> 
> I also saw this post:
> Let's assume that "the curve" at IETF is Curve25519. It doesn't appear to be an undisputed winner right now, but let's assume that it is universally accepted at every working group at IETF and is added to every IETF protocol soon.
> 
> 
> There is a significant US federal market with Suite B, FIPS, or at least SP 800 XXX that in some cases supports multiple product lines for a company. Beyond that, one credit that Suite B gets is that Suite B provided a clear and safe path for anybody who wanted to add ECC to their products. It assured interoperability on the Internet and coverage for the US government sector in a single standard. It made it much safer to create persistent data structures that should exist for decades. Not everybody liked it, especially outside of US, but P-256 was and still a method to bootstrap into ECC.
> 
> 
> I would like to hear your thoughts on the long-term view regarding standardization.
> 
> * Curve25519 becomes so pervasive that NIST adopts it. It replaces P-256 as a standard [Should reaching out to NIST be on the roadmap at some point before that expected acceptance?]
> 
> * Curve25519 exists parallel to P-256 (and P-256 becomes just a US national standard) [In this case products accept that Curve25519 + all the national standards is a typical product requirement]
> 
> * Curve25519 is viewed as a couple-of-years forward solution and so the questions of integration with other standards is out of scope for the Curve25519 decision [perhaps because the focus is on currently common Intel x86 CPUs, ARMs?]
> 
> <other possibilities, I am sure>…

Curve25519 becomes fairly widely implemented, and there are standards to define its use in TLS and IKE. Some browsers and a few VPN products implement it, as do a few server libraries such as OpenSSL. After a while, Curve25519 and P-256 exist in parallel, much like Camelia and AES, but because NIST is more prominent in users’ minds than the IETF, P-256 remains what people think is the “gold standard”, but some prefer Curve25519 for its performance.

Just another possibility…

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Jul 2014 06:16:48 -0700

Trying to predict what NIST will do with FIPS-140 certification is silly. Even they don't know from year to year. The NIST of today is not the NIST of 14 months ago; it is likely that there will be other major shifts in NIST's view of itself and what it has to do to stay relevant.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Jul 2014 06:33:27 -0700

On Jul 1, 2014 6:17 AM, "Paul Hoffman" <[email-masked]> wrote:
>
> Trying to predict what NIST will do with FIPS-140 certification is silly.
Even they don't know from year to year. The NIST of today is not the NIST
of 14 months ago; it is likely that there will be other major shifts in
NIST's view of itself and what it has to do to stay relevant.

I had this concern at the CFRG meeting. Kevin Igoe said that the NSA had no
objections to Curve 25519 being in Suite B.

There is a legacy cert and software problem: it's likely software will need
to deploy several curves for compatibility with x509 certs.

Finally, OpenSSL supports non FIPS algorithms as well as FIPS algorithms.
It's not impossible to do the same.

Sincerely,
Watson Ladd
>
> --Paul Hoffman
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 01 Jul 2014 09:24:20 -0700

> Trying to predict what NIST will do with FIPS-140 certification is silly. Even they don't know from year to year. The NIST of today is not the NIST of 14 months ago; it is likely that there will be…

You might be surprised that there many product managers building secure 
products today who never heard of Curve25519 and think that it is silly 
to even consider any crypto outside of NIST.

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 01 Jul 2014 09:26:12 -0700

On 07/01/2014 06:33 AM, Watson Ladd wrote:
>
> On Jul 1, 2014 6:17 AM, "Paul Hoffman" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > Trying to predict what NIST will do with FIPS-140 certification is
> silly. Even they don't know from year to year. The NIST of today is not
> the NIST of 14 months ago; it is likely that there will be other major
> shifts in NIST's view of itself and what it has to do to stay relevant.
>
> I had this concern at the CFRG meeting. Kevin Igoe said that the NSA had
> no objections to Curve 25519 being in Suite B.
>

This is a useful information. It would be even more useful if some 
statement of this sort was public and by NIST/NSA.

> There is a legacy cert and software problem: it's likely software will
> need to deploy several curves for compatibility with x509 certs.
>
> Finally, OpenSSL supports non FIPS algorithms as well as FIPS
> algorithms. It's not impossible to do the same.

I am not sure I see an argument here. OpenSSL had always many ECC curves 
but vendors were making sure to disable them at compile time. Only with 
great caution they would enable specifically P-256, and sometimes P-384, 
after careful consideration.

...

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Jul 2014 20:27:44 +0300

On Jul 1, 2014, at 7:24 PM, Andrey Jivsov <[email-masked]> wrote:

> You might be surprised that there many product managers building secure products today who never heard of Curve25519 and think that it is silly to even consider any crypto outside of NIST.

It certainly makes sense for anyone who plans on selling anything to US government agencies or state and local government bodies in the US. They will have the NIST algorithms. So there’s AES and SHA-whatever, and P-256. 

But look at browsers. The four most popular are made by US-based companies. And yet they all support non-NIST-approved algorithms in TLS, in addition to NIST-approved algorithms. Currently not EC curves, but at least the people who work for these vendors and participate here and on the TLS list are among those interested. 

IPsec is somewhat less diverse, but there’s plenty of CAST and Camellia and IDEA and Blowfish and MD5 and Tiger there as well. There’s Camellia at least in SSH as well.

If Curve-25519 allowed me to publish a higher figure for “Main Modes per second”, or “full TLS handshakes per second”, I would implement it without thinking twice, making sure to disable it in the special “FIPS mode”.

Yoav

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Tue, 1 Jul 2014 19:10:20 +0000

Let me clarify a wee bit.  In the LONG RUN we don’t see any problems with Curve  25519,
but we don’t change things on a dime.  Crypt design has been and should be conservative,
both to minimize the chance of adopting a flawed system and to recoup the multi
million dollar investment needed to field a new system or make changes to an existing
system.  Military procurement and deployment makes a glacier look fast.  Curve 25519
will not be in Suite B in the near future, but we don’t want to hold other folks back from
moving forward so long as the NIST curves remain at least a MAY implement.

That said, some folks have come forward requesting that future curves, when put
in Weierstrass form,  have a=-3, i.e. y^2 = x^3 -3*x + b.  As best I can tell a=-3 seems to be
hardwired into some of our gear.  Also we’ll need a 192-bit secure curve (i.e. ~2^384
points on the curve).

And as always there are cert problems.  Ah for the good old days, when certs were viewed
to be a solution to our problems rather than a source of endless headaches!

From: Cfrg [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Tuesday, July 01, 2014 9:33 AM
To: [email-masked]
Subject: Re: [Cfrg] My comments on TLS requirements from today's interim

> Trying to predict what NIST will do with FIPS-140 certification is silly. Even they don't know from year to year. The NIST of today is not the NIST of 14 months ago; it is likely that there will be…

I had this concern at the CFRG meeting. Kevin Igoe said that the NSA had no objections to Curve 25519 being in Suite B.

There is a legacy cert and software problem: it's likely software will need to deploy several curves for compatibility with x509 certs.

Finally, OpenSSL supports non FIPS algorithms as well as FIPS algorithms. It's not impossible to do the same.

Sincerely,
Watson Ladd
> [email-masked]<mailto:[email-masked]>