Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves

Patrick Longa Pierola <plonga@microsoft.com> Sun, 20 July 2014 20:04 UTC

Return-Path: <plonga@microsoft.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634B81A0070 for <cfrg@ietfa.amsl.com>; Sun, 20 Jul 2014 13:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 z4E0zs3N53mq for <cfrg@ietfa.amsl.com>; Sun, 20 Jul 2014 13:04:38 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A4E1B29F9 for <cfrg@irtf.org>; Sun, 20 Jul 2014 13:04:37 -0700 (PDT)
Received: from BY2PR03MB474.namprd03.prod.outlook.com (10.141.141.149) by BY2PR03MB475.namprd03.prod.outlook.com (10.141.141.150) with Microsoft SMTP Server (TLS) id 15.0.990.7; Sun, 20 Jul 2014 20:04:34 +0000
Received: from BY2PR03MB474.namprd03.prod.outlook.com ([10.141.141.149]) by BY2PR03MB474.namprd03.prod.outlook.com ([10.141.141.149]) with mapi id 15.00.0990.007; Sun, 20 Jul 2014 20:04:34 +0000
From: Patrick Longa Pierola <plonga@microsoft.com>
To: "rsalz@akamai.com" <rsalz@akamai.com>, Nigel Smart <nigel@cs.bris.ac.uk>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
Thread-Index: AQHPpC8rQYOQwnvnWUy4VjgkuzYLoZupVtYw
Date: Sun, 20 Jul 2014 20:04:33 +0000
Message-ID: <4f25233deb804496b4b17b70f01d9b31@BY2PR03MB474.namprd03.prod.outlook.com>
References: <53CBDFF8.5050204@cs.bris.ac.uk>
In-Reply-To: <53CBDFF8.5050204@cs.bris.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.47.83.223]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02788FF38E
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(199002)(51704005)(80022001)(83322001)(105586002)(106356001)(87936001)(76176999)(95666004)(50986999)(106116001)(85306003)(46102001)(86612001)(2656002)(64706001)(20776003)(4396001)(33646002)(66066001)(86362001)(77982001)(99286002)(74316001)(21056001)(31966008)(74502001)(74662001)(107886001)(107046002)(81342001)(76576001)(85852003)(79102001)(76482001)(81542001)(54356999)(99396002)(83072002)(101416001)(92566001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB475; H:BY2PR03MB474.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/lI07iWcExmlUYuiv7eadQ3q5Zxw
Subject: Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jul 2014 20:04:41 -0000

> Nigel Smart wrote:
> Note the request is for new ELLIPTIC CURVES not elliptic curve PROTOCOLS
> Thus any curve should be IMHO usable with any STANDARD protocol, in any STANDARD way of implementing the protocol. Without this constraint one is bound to get implementation errors.

>  - Curve25519 is a combined curve/protocol; so is out of scope IMHO. As
>    someone is bound to use the underlying curve with some other protocol
>    and make mistakes.

> Benjamin Black is correct; having new types of this that and the other for a marginal security gain, and/or a marginal performance gain is IMHO inviting problems.
 
IMO these are important points made by Ben and Nigel. To the point: so far I haven't seen compelling evidence to want to "hardwire" a curve to a protocol. Many well-designed curves can be used for different protocols without restrictions, with the same (or potentially stronger) security assurances and with virtually equivalent performance. OTOH, tying curve/protocol can bring potential compatibility problems, make agility harder, increase complexity of implementations (from a narrow perspective "hardwired" curve/protocol implementations might seem to simplify things, however in actual deployments in which many other components participate this is not necessarily the case), etc.

As a rule of thumb, IMHO a solid curve selection process should focus on curves (and reference implementations) that apply to a flexible number of protocols and, in special, to ECDHE and ECDSA. 

>> Nigel Smart wrote:
>>   - Curve25519 is a combined curve/protocol; so is out of scope IMHO. As
>>     someone is bound to use the underlying curve with some other protocol
>>      and make mistakes.
>
> Rich Salz wrote:
> Strongly disagree.  Many find the performance issues compelling, and the fact that it defines everything down to the bytes on the wire highly attractive; the fact that high-quality reference implementations are available makes the "someone will get it wrong" not particularly interesting.

Can you point me out the reference implementations that make the performance that compelling? Please, if you can, back your response with precise performance numbers for ECDHE (IMO this is the most important metric to evaluate performance in this IETF process). This is important because we wouldn't want to dismiss strong compatibility features at the expense of negligible speedups.

Best regards,

Patrick