Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

[Michael StJohns <[e-mail]>]

Hi -

I waited about 48 hours to get most of the comments out there. With 
respect to Stephen's note, I mostly agree with his conclusions with 
respect to the current consensus within the IETF.  But I did want to 
address one particular comment he made as well as respond to some other 
comments.

EKR is correct that this is a larger question than TLS, unfortunately 
we're first up.

So first on "small but vocal minority agitating":

On 6/27/2014 7:34 AM, Stephen Farrell wrote:
>
> Also, I have to say the language in Mike's original mail was,
> at best, unfortunate, e.g. "small but vocal minority agitating"
> is not likely to kick off a calm reasoned debate, and is
> definitely not going to help the TLS WG keep focused on its
> work so I really hope folks don't respond in kind, and if the
> chairs want to loudly stomp on threads with such language
> (regardless of source and mostly regardless of topic) they
> have my full backing.
>

I'm not exactly sure what Stephen is objecting to in the above. Here's 
what I saw from in-person and email discussions:

A small group that was very vocal about throwing out anything to do with 
NIST/US Government crypto advocating for the use of Curve25519 as a 
replacement for the NIST curves and crypto and also advocating that it 
be the one true curve for the IETF.

A larger group that was more focused on performance and security and 
talking about the advantages of Curve25519 and then incidentally 
mentioning their discomfort with the possibility of tampering on the 
NIST curves.  (Hi Alyssa....)

A slightly larger group that was "looks OK to me as an additional 
system" (maybe the majority of the CFRG based on transcripts?)

An even larger group that was "crypto?  Meh! Tell me what to use".

What I didn't see was hue and cry from ACI Worldwide, American Express 
Company, American Financial Services Association, Bank of America, 
Capital One, Certicom Corporation, Citigroup, Inc., Deluxe Corporation, 
Diebold, Inc.,Discover Financial Services, eFunds Corporation, Federal 
Reserve Bank, First Data Corporation, Fiserv, Hewlett Packard, Hypercom, 
IBM Corporation, Ingenico, J.P. Morgan Chase & Co, KPMG LLP, MagTek, 
Inc., MasterCard International, National Association of Convenience 
Stores, National Security Agency, NCR Corporation, Savvis, SWIFT, The 
Clearing House, Unisys Corporation, University Bank, VeriFone, Inc., 
VECTORsgi, VISA, Wachovia Bank,  and Wells Fargo Bank to throw out the 
existing EC cryptography.

The above list of companies are those listed in the preface of the X9.62 
ECDSA crypto standard as participants/approvers for X9 and ultimately a 
group like that or larger are ones that will decide whether or not 
specific crypto will be acceptable for the commercial community. [X9.62 
ECDH had a similar group, but would have required more work on my part 
to edit it down to the company list]

In the scheme of things, the IETF participants are - sorry - a very very 
small minority of the people who have to be happy with Curve25519.  
Unlike all the other EC stuff we do (to specifically include the 
brainpool curves), Curve25519 is NOT within an accepted cryptography 
standard.   For the IETF to decide it wants to go into such business 
seems to be way outside our competences.

My original suggestion was meant to address the "NIST curves might be 
booby trapped" concerns of the first two groups I note above in a way 
that would be acceptable to that larger commercial community and for no 
other reason.

Going back to Stephen's comment - Stephen, would you care to craft a 
better description of the first group for me?  I didn't mean to offend, 
but I seriously don't think my "language" should be "loudly stomped" and 
I'm unclear why you do.

 >>>>  "IPR Issues":

The specific set of IPR issues that concern me are the license and 
copyright with respect to DJB's basic work.    Unless there is a 
"perpetual, paid up, world-wide, irrevocable" license for anything that 
he's done (or could do in this space) there are possible future issues.  
Something as simple as invoking the already existing copyright on the 
curve data could be problematic.

Note that I'm not saying this will happen, or that its even 
contemplated,  but it's a potential problem that should be resolved 
formally and legally.

(It's possible there is such a document, but I went looking and didn't 
find it.  Some of this is tagged "public domain" but that's probably 
insufficient for most lawyers).

If DJB et al is willing to transfer change control/copyright/patent 
rights/moral rights to the IETF (via appropriate documentation), and the 
IETF is willing to publish an actual standard then this objection goes away.


 >>>>> "CFRG has selected Curve25519 as the preferred curve for the IETF"

This statement was made in varying forms from "curve25519 is secure 
enough to be used" to "curve25519 is *the* curve for the IETF" in the 
discussion on this thread.  From reading the jabber log reference that 
was provided, I'd say that the former statement is more correct than the 
latter, but that's based on very little documentary evidence one way or 
the other.

In any event, there are probably a few procedural issues that need to be 
resolved before Curve25519 becomes "the" preferred curve and system for 
the IETF.  First is that the CFRG is a IRTF working group and not an 
IETF working group.  I believe that the CFRG can make recommendations, 
but the adoption of those recommendations as a BCP is an IETF issue.   
In the transcript I read, Yoav noted that a draft and RFC needed to be 
done.  So my take on the current state is that the CFRG has decided by 
voice vote/hum to make some sort of recommendation, but such 
recommendation has not yet been formalized.   Once that's done, then the 
IETF in the person of the SAAG, Security Area AD's and the IESG would 
need to take the recommendation and turn it into a BCP along with all 
the documentation necessary to make Curve25519 into a useable standard 
(e.g.  draft-josefsson-*, with TLS specifics removed so the crypto can 
be used in a general fashion).

*sigh* If the IETF is really going to get into the business of 
standardizing crypto, we need to get the process for doing so right the 
first time rather than just plugging it in to TLS and hoping we don't 
have to redo it over and over again.


Mike