Re: [TLS] On Curve25519 standardization

[Michael StJohns <[e-mail]>]

Someplace in the middle of all this the question I asked seems to have 
gotten lost.  Basically, "would generating IETF curves obviate the need 
for Curve25519 or others?" which I would say got answered "no".  The 
rest of all this is a side show with how Curve25519 gets into the IETF 
toolkit. 'nuff said.

On 6/30/2014 2:13 PM, Salz, Rich wrote:
> So on the one side, folks at the CFRG meeting and such said they want an IETF RFC document on how to use and represent 25519.  That the external documents aren't enough.
>
> On the other side, you are saying "no half measure" and that if we specify how to implement and use 25519, then we are writing a crypto standard and we've never done that before.
>
> Do I have that right?

I would agree with "need a document to represent and use 25519", its who 
said that and how it was said that I'm unclear on.   That document will 
have the form of a crypto standard irrespective of who writes it.  If it 
gets published like each and every other RFC we've done on crypto - as 
Informational and externally originated, then it isn't anything new.   
If we run it through our standards process, then it is.

>
> If yes, then my reply is "so what."  Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door.

I actually used the word "assurance".  Standards bodies don't get stuck 
with liability per se.

The IETF has an open process, scope of expertise and a reasonable 
commercial and international reputation.  Putting the IETF stamp of 
approval (in the form of placing it on the standards track) on a 
specific cryptographic algorithm and its associated standards lends that 
reputation to the standard more or less with a hit to the reputation if 
there's a failure.  If we want to begin doing this for cryptography in 
general, then we need to understand the real-world implications, both of 
the endorsement and possible failures.

Mike