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

On Jun 30, 2014 9:31 AM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> 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.

Okay, we publish it as informational. But wait, that's being done by the
CFRG. So what is the problem here? We haven't done it before is not much of
a problem.

We do update informational RFCs: I think you are reading far more into the
distinction vis a vis IETF inolvement then actually exists.
>
> 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
>>>
>>
>>
>