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

Two opposing views on whether Curve25519 is destined for IETF 
standardization status.... and hence some of my confusion.

Rich - "here’s how to do the math for 25519 and other things needed to 
interoperate" is sort of the definition of what a cryptographic standard 
is - only question is whether its an externally owned/maintained 
document offered as an Informational RFC or an IETF standards track 
document.  If the latter, then the standard  (and indirectly the math) 
gets an IETF imprimatur and we haven't offered those - yet - for 
cryptographic standards.

Mike

On 6/30/2014 12:36 AM, Watson Ladd wrote:
> On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich <rsalz@akamai.com> wrote:
>> Ø  Implication: The IETF will have to make some pronouncement or assurance
>> as to the viability of Curve25519 to the wider world.  The IETF will have to
>> maintain the Curve25519 standard.
>>
>> Mike, I know you’ve been involved in this stuff since before this stuff
>> existed J, but I don’t understand this. Why do we have to make any assurance
>> about anything other than ‘here is how to interoperate using 25519 in TLS’?
> No, we are defining a standard, and we are making assurances. Let's
> not kid ourselves: SPF might say experimental, but if you try to send
> mail without it, you'll find out just how much of a standard it is. As
> for making assurances, if someday a massive break is discovered in TLS
> 1.3 because we neglected cryptographic knowledge, we will rightfully
> be blamed for it.
>
> If 25519 was ROT13, a proposal to include it would rightfully be
> laughed out of this WG. We've established the principle, now we're
> just haggling over its limits.
>
> Sincerely,
> Watson Ladd
>
>>
>>
>> We’re not defining a standard, we’re not assuring the world about anything.
>> We’ll have an RFC that says “here’s  how to do the math for 25519 and other
>> things needed to interoperate” and we’ll have other RFC’s that say “here’s
>> how to use that curve in this protocol.”
>>
>>
>>
>> Why does it need to be more than that?  I know that I am not alone in this
>> confusion.
>>
>>
>>
>>                  /r$
>>
>>
>>
>> --
>>
>> Principal Security Engineer
>>
>> Akamai Technologies, Cambridge, MA
>>
>> IM: rsalz@jabber.me; Twitter: RichSalz
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>