Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

"Salz, Rich" <rsalz@akamai.com> Sun, 12 January 2014 19:21 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 442421AE013 for <tls@ietfa.amsl.com>; Sun, 12 Jan 2014 11:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 YNLupHf9-oZ8 for <tls@ietfa.amsl.com>; Sun, 12 Jan 2014 11:21:31 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id F2F231AE01B for <tls@ietf.org>; Sun, 12 Jan 2014 11:21:28 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0140F47398; Sun, 12 Jan 2014 19:21:18 +0000 (GMT)
Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E937947394; Sun, 12 Jan 2014 19:21:17 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id DE8AEFE054; Sun, 12 Jan 2014 19:21:17 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.77]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sun, 12 Jan 2014 14:21:17 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: "tls@ietf.org" <tls@ietf.org>, "Stephen Farrell (stephen.farrell@cs.tcd.ie)" <stephen.farrell@cs.tcd.ie>, "Sean Turner (turners@ieca.com)" <turners@ieca.com>
Date: Sun, 12 Jan 2014 14:21:16 -0500
Thread-Topic: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement
Thread-Index: Ac8Pr/8VO9F1c/nhTsmmkBsl/ZuFHwAGrM6w
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E8766BFF@USMBX1.msg.corp.akamai.com>
References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D17F30.1090008@drh-consultancy.co.uk> <52D2AB07.7010806@polarssl.org> <52D2B678.7010302@drh-consultancy.co.uk> <52D2BD0B.1020007@polarssl.org>
In-Reply-To: <52D2BD0B.1020007@polarssl.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Simon Josefsson <simon@josefsson.org>
Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement
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: Sun, 12 Jan 2014 19:21:32 -0000

I don't want this question to get lost in the general discussion so I am explicitly addressing this to the AD's

>> I think we should keep this consistency and have the point format for 
>> the new curves defined in one standard, whatever that might be.

> Since this format may be used by more than just TLS, and was originally defined outside the IETF, what would
> be the most appropriate place to discuss extending it?

Some folks have been working on a concrete proposal, which is that we "take" 0x41 as a new marker byte in ECPoint, and use that to mean "key format defined by the curve"  Ask IANA to maintain a curve point-format registry.  For example, Curve25519 would have 0x41 followed by the 32 bytes of x-value for the key.

So, where should such a document be started?

Many of us are feeling pressure to implement ECDHA to get PFS for our customers, and see the efficiency of Curve25519 as very important.  That is, the  clock is ticking...

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA