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

[Yoav Nir <[e-mail]>]

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

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

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