IETF Logo Mail Archive

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

"Salz, Rich" <rsalz@akamai.com> Mon, 30 June 2014 03:12 UTC

Return-Path: <rsalz@akamai.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 6D6621A0100 for <tls@ietfa.amsl.com>; Sun, 29 Jun 2014 20:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 omXAVLzfBhP1 for <tls@ietfa.amsl.com>; Sun, 29 Jun 2014 20:12:35 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1471A00FF for <tls@ietf.org>; Sun, 29 Jun 2014 20:12:34 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9CFFC482B5; Mon, 30 Jun 2014 03:12:34 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 87C54482B4; Mon, 30 Jun 2014 03:12:34 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 5A34F9803D; Mon, 30 Jun 2014 03:12:34 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Sun, 29 Jun 2014 23:12:33 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Michael StJohns <msj@nthpermutation.com>, Eric Rescorla <ekr@rtfm.com>
Date: Sun, 29 Jun 2014 23:12:32 -0400
Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
Thread-Index: Ac+T2FHjkHpuLs2/QW+KuP9wo9clfwAN7FUw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.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>
In-Reply-To: <53B07640.2050000@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95USMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gJHheUo3CiSQ7sop5RX71b02ah8
Cc: "tls@ietf.org" <tls@ietf.org>
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 03:12:36 -0000

Ø  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 ☺, 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’?

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<mailto:rsalz@jabber.me>; Twitter: RichSalz

v2.23.0 | Report a Bug | By Email