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

Watson Ladd <watsonbladd@gmail.com> Mon, 30 June 2014 16:45 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716D81A03B9 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 09:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3WiKs_meIg1 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 09:45:43 -0700 (PDT)
Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A311A03B5 for <tls@ietf.org>; Mon, 30 Jun 2014 09:45:32 -0700 (PDT)
Received: by mail-yh0-f52.google.com with SMTP id a41so5069910yho.11 for <tls@ietf.org>; Mon, 30 Jun 2014 09:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1KUDv67UXo8x42TQSn3kd4DtCcWmgS5Tfw0p4kOU3kA=; b=py0GsLwj/m/7WNTbfbZBFUMYFKL8FHnPfmXY4Ht4bpoJzmP69XZnZZLmTQ3nxiW1jV W1Lar2M4X4jGXFItXe+DjH/12uvpaBF98l/rK/F0+CfHpkMriVCYyGCjujqJ3gnGWXIp nbhj84E+aXEjX40k+JKQ9FBUAWmx3VSeuC4tglP0VWiGHc8LGropGunZxk4kxtJlrEoI VaCHA8x+H7h7jIC3vafY5zr6GT5jk7HsM/667bXj8OLr5jTOHdZXSOLKbGSr83haFxDm 8co29Cb0/khbXFs+2NAcBzQp0vzqQx05gDJiJVoZFmtMnsoKsfsha0SM3S3cj2mKjJlu Ivqw==
MIME-Version: 1.0
X-Received: by 10.236.152.169 with SMTP id d29mr14968803yhk.83.1404146731698; Mon, 30 Jun 2014 09:45:31 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Mon, 30 Jun 2014 09:45:31 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Mon, 30 Jun 2014 09:45:31 -0700 (PDT)
In-Reply-To: <53B190E7.6050800@nthpermutation.com>
References: <53AC97B8.2080909@nthpermutation.com> <CABcZeBN5uY4bteXW=OFC1z3ANoSC8AqxG6E6artdOKPF=VxdJg@mail.gmail.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <CACsn0cmYbPeyUCMvRc=8MqVGMDSv1mKbxiQutqpPw_oR6cfD-A@mail.gmail.com> <53AF517F.7050504@nthpermutation.com> <CABcZeBMs+03GefqNaBbhF8FRdw_Pmpe6NkDqesssb-FruRaEdw@mail.gmail.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> <CACsn0cm1TvZsdreOK7WejWqOqU4SNAcvKRyy5sSZMJjyYzq1=Q@mail.gmail.com> <53B190E7.6050800@nthpermutation.com>
Date: Mon, 30 Jun 2014 09:45:31 -0700
Message-ID: <CACsn0cnOL0z0MMsvZfFuVWPrW5-pxgytLEgSu9kx_og2DKicqg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=20cf3040ede827d29004fd106377
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SM2yujXgMsY2cjkk80NpjbGSUeY
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 16:45:47 -0000

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