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

"Salz, Rich" <rsalz@akamai.com> Mon, 30 June 2014 18:13 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 F10091A03E5 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 11:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N9NPg-4O6MPK for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 11:13:17 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4201A042D for <tls@ietf.org>; Mon, 30 Jun 2014 11:13:08 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A686B16560A; Mon, 30 Jun 2014 18:13:07 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9BD071655D4; Mon, 30 Jun 2014 18:13:07 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 805E81E03D; Mon, 30 Jun 2014 18:13:07 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 30 Jun 2014 14:13:07 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Michael StJohns <msj@nthpermutation.com>, Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 30 Jun 2014 14:13:06 -0400
Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
Thread-Index: Ac+UgMX7vMFeUWjBQb+BAxYhdMDWbwADap3g
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFD52@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> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> <CACsn0cm1TvZsdreOK7WejWqOqU4SNAcvKRyy5sSZMJjyYzq1=Q@mail.gmail.com> <53B190E7.6050800@nthpermutation.com>
In-Reply-To: <53B190E7.6050800@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wy-cVyYfsJeT3ash4DqlM8XHkLo
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 18:13:20 -0000

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?

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.

Whatever.  Angels on the head of a pin.
	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSalz