[Cfrg] Notes on curve selection from IETF90

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Fri, 25 July 2014 15:03 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C56CF1B29CB for <cfrg@ietfa.amsl.com>; Fri, 25 Jul 2014 08:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ow4tes16PWCy for <cfrg@ietfa.amsl.com>; Fri, 25 Jul 2014 08:03:37 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C93F1B29C1 for <cfrg@irtf.org>; Fri, 25 Jul 2014 08:03:36 -0700 (PDT)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ( by DBXPR03MB381.eurprd03.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 15:03:33 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([]) by DBXPR03MB383.eurprd03.prod.outlook.com ([]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 15:03:33 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Notes on curve selection from IETF90
Date: Fri, 25 Jul 2014 15:03:32 +0000
Message-ID: <CFF7E6CD.28F00%kenny.paterson@rhul.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02830F0362
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(92726001)(99396002)(92566001)(77982001)(74482001)(19580395003)(2656002)(4396001)(19580405001)(50986999)(87936001)(21056001)(31966008)(66066001)(86362001)(80022001)(74662001)(74502001)(95666004)(83322001)(85306003)(101416001)(106356001)(105586002)(107046002)(107886001)(79102001)(81342001)(2351001)(36756003)(64706001)(85852003)(81542001)(15975445006)(83072002)(83506001)(54356999)(20776003)(106116001)(76482001)(110136001)(229853001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FF63EF41DA7ACB4FA2024230B4F8D48A@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ACXW_1WcmpM6x6jertEwlKcYcDA
Subject: [Cfrg] Notes on curve selection from IETF90
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: Fri, 25 Jul 2014 15:03:41 -0000


At IETF90, CFRG was asked to report back to the TLS WG on progress on
curve selection. I prepared and presented some slides which in theory you
should be able to find online here:


But that pdf seems to be empty right now. So I thought it would be useful
to re-present some of the slides here in text format, as a snapshot of
where I think we are in the process and discussion on requirements. Note
that the views represented here are those of chairs and are based on
discussions on the list and discussions at the meeting here in Toronto.

Comments welcome.





­Wednesday 1300-1500
­Roughly 90 minutes presentation + discussion on new ECC.
­Overview talk on ECC old and new from Tanja Lange (TU Eindhoven).
­Talk on NUMS curves from Brian LaMacchia and Craig Costello (Microsoft).
­Talk on Curve25519 and friends from Dan Bernstein (UIC/TU Eindhoven).
­Lively Q&A/discussion, continued at ISRG dinner.

Emerging Areas of Consensus on Requirements

-Protection against side-channel attacks strongly desired.

-Basic elements of curve selection ­ defined over prime field; prime or
order; twist security.
­-Not always needed, but we can achieve these at no real cost.

-Need to support existing algorithms.
­-Strong steer from TLS WG.
­-ECDHE, EC-DSA, and maybe ECDH.
­-Interop with existing wire formats desirable, not essential.
­-Versus potential perf. gains from adopting new algs

-Need for rigidity in curve generation process.
­-Trustable curve generation process is important.
­-It¹s a primary motivation for this work.
­-How much rigidity is enough to satisfy public opinion?

Emerging Areas of Consensus on Curve Form

-Switch from Weierstrass-only form to alternative forms
(Montgomery/Edwards/twisted Edwards)
­-Deployability of new W.-only form curves not significantly easier, even
though there¹s a large deployed code base for W.-only form curves.
­-Much easier side-channel protection without perf. sacrifice using alt.
­-Co-factor > 1 for alt. forms has potential for implementation errors.
­-Overall, tenatively, alt. forms seem to be the way to go.

-Growing realisation amongst non-experts.
­-It¹s complicated!

Current Areas of Debate

-Specific implementation detail at 128-bit security level:
­-(Montgomery + twisted Edwards for ECDHE + point conversions) versus just
twisted Edwards for ECDHE?
­-Related implications for wire format.

-What does ephemeral mean?
­-Server-side: every key exchange or every 10s or every hour?
­-Has implications for selection of curve form (costs of fixed base versus
base computations).

-Actual choice of specific curves.

Summary (personal view)

-In terms of perf+security, there¹s not much to choose between the
competing alt. (i.e. non-W.-only) curve proposals at each security level.

-We¹re making progress; rough consensus on requirements should be possible.

-Getting consensus on selection of curves will require some give and take
from competing proposers.