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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 14 July 2014 19:49 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56F01A00B2 for <cfrg@ietfa.amsl.com>; Mon, 14 Jul 2014 12:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 TL-Yc3g4nNxu for <cfrg@ietfa.amsl.com>; Mon, 14 Jul 2014 12:49:45 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08571A00A8 for <cfrg@irtf.org>; Mon, 14 Jul 2014 12:49:44 -0700 (PDT)
Received: from DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) by DBXPR03MB527.eurprd03.prod.outlook.com (10.141.12.154) with Microsoft SMTP Server (TLS) id 15.0.980.8; Mon, 14 Jul 2014 19:49:42 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.0.985.8; Mon, 14 Jul 2014 19:49:42 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0985.008; Mon, 14 Jul 2014 19:49:41 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Formal request from TLS WG to CFRG for new elliptic curves
Thread-Index: AQHPn5zA174av2OH7UK/rj2CeH46ng==
Date: Mon, 14 Jul 2014 19:49:41 +0000
Message-ID: <CFE9F2DE.26E5A%kenny.paterson@rhul.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [78.146.58.177]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02723F29C4
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(51704005)(24454002)(504964003)(479174003)(164054003)(15975445006)(83506001)(74662001)(16601075003)(15202345003)(86362001)(66066001)(83072002)(64706001)(74502001)(81342001)(92566001)(74482001)(85852003)(46102001)(87936001)(81542001)(50986999)(83322001)(19580405001)(19580395003)(20776003)(106116001)(105586002)(31966008)(2351001)(79102001)(107046002)(110136001)(80022001)(54356999)(229853001)(99396002)(21056001)(76482001)(101416001)(2656002)(92726001)(85306003)(4396001)(95666004)(77982001)(36756003)(561944003)(106356001); 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="us-ascii"
Content-ID: <883358FCAFAEA04E965A2454AFAA9115@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-OriginatorOrg: rhul.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Hvihr_yQhVB_Qdl-mtwTdVbHGiU
Subject: [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: Mon, 14 Jul 2014 19:49:48 -0000

Dear CFRG,

CFRG has received a formal request from the TLS Working Group for
recommendations for new elliptic curves. Specifically, the TLS WG would
like CFRG to recommend:

- Curves suitable for both key establishment and digital signature
  (though the same curves need not be used for both purposes).

- One proposed curve or set of curves at the following security
  levels: 128-bit (~256-bit curve) and 256-bit (~512 bit curve).
  192-bit security is optional.

Note that these curves are not intended to supplant current curves in
widespread use, but rather to supplement them. Full details of the request
can be found in the e-mail from the TLS WG chairs below.

The CFRG chairs will coordinate a response to this request from the CFRG
readership. Ideally we will reach a rough consensus through discussion on
the
list and at the upcoming IETF 90 meeting in Toronto. While no deadline is
set for our response to the TLS WG, we should aim to have one ready within
2 months.

We regard this as a major work item for CFRG and one where CFRG can
provide real value to the TLS WG and the IETF more widely. So we encourage
(and indeed request) active participation from the widest set of
participants on this project.

As a first step, we propose to discuss the requirements for new curves for
a period of 2 weeks. Using an agreed set of requirements, in a second
step, we will then evaluate different curve proposals (including extant
proposals and any emerging ones) for a period of 4 weeks. In a final
period of 2 weeks, we will produce a proposal for the TLS WG and seek
consensus on it.


The first step, running for 2 weeks, begins here.

A starting point for requirements can be found in David McGrew's recent
CFRG post
(http://www.ietf.org/mail-archive/web/cfrg/current/msg04461.html) and
reproduced here:

----

Simplicity

   R1.  Desired: easy to understand and implement [1]

Efficiency

   R2.  Required: amenable to compact implementations and fast
   implementations, across both small and large processors [1]

   R3.  Desired: re-use components between signatures and key exchange
   algorithms [3]

Intellectual Property

   R4.  Required: available worldwide under reasonable and well
   understood licensing terms [1]

   R5.  Desired: available worldwide under royalty-free licensing
   terms [1]

Interoperability

   R6.  Desired: can be used with current software implementations
   (using different curve parameters) of TLS, PKIX, SSH, and IKE [4]

   R7.  Desired: can be used within current ECC standards of TLS,
   PKIX, SSH, and IKE [4]

Security

   R8.  Required: amenable to constant-time implementations, to avoid
   side channel attacks [2]

   R9.  Required: resist twist attacks [2]

   R10.  Required: curve parameters should have good provenance;
   random curves should be provably pseudorandom [5]

   R11.  Desired for key exchange: resist invalid curve attacks [2];
   note that complete addition laws help and are thus desirable [2].
   (Note that the use of ephemeral keys also resist such attacks.)

   R12.  Required for PAKE: indistinguishability of curve points from
   random strings [2]

Footnotes:

   [1] Original criteria set out for the Advanced Encryption Standard,
       which is equally applicable to ECC.  National Institute of
       Standards and Technology (NIST) of the United States, 1998.

   [2] Daniel J. Bernstein and Tanja Lange. SafeCurves: choosing safe
       curves for elliptic-curve cryptography.
       http://safecurves.cr.yp.to <http://safecurves.cr.yp.to/>
<http://safecurves.cr.yp.to/>;, accessed
April 2014.

   [3] Criteria identified by David McGrew, 2014.

   [4] Criteria identified by Russ Housley, TLS WG meeting at IETF89.

   [5] Criteria widely acknowledged on CFRG email list during 2014.

----


Our first request, then, is that you consider these requirements, and
provide your views on their appropriateness, completeness, and individual
classifications (required/desired). We will continue that discussion for 2
weeks, until the end of the IETF meeting in Toronto. The chairs will then
compile a consensus-based list of requirements of the above form, after
which we will move to the second step.

We thank you in advance for your participation in this important task.

Regards

Alexei, Kenny and Kevin (CFRG co-chairs)




On 11/07/2014 05:44, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>;
wrote:

>CFRG Chairs and Security ADs,
>
>TLS WG would like to formally request that the
>CFRG make a recommendation for new ECC group support for TLS
>and other similar applications. Specifically, we request that CFRG
>recommend the following:
>
>- Curves suitable for both key establishment and digital signature
>  (though the same curves need not be used for both purposes).
>
>- One proposed curve or set of curves at the following security
>  levels: 128-bit (~256-bit curvee) and 256-bit (~512 bit curve).
>  192-bit security is optional.
>
>If the same curves are used for key establishment and signature, this
>would be a recommendation for two curves.  If different curves are
>used, this would be a recommendation for four curves.
>
>In addition to a recommendation, we also request that the CFRG provide
>a technical rationale for their selection.
>
>If the CFRG does not feel comfortable making a single set of
>selections, we propose that they select a small number of potential
>choices with a detailed technical analysis of the advantages and
>disadvantages of each selection and that the Security ADs sponsor a
>process (perhaps via SAAG) to narrow it down to the specification
>above.
>
>For clarity, we are not currently requesting that CFRG replace or
>profile the existing curves in RFC4492 and RFC 7027, although we are
>also not ruling out such an effort in the future. The current request
>is for a new set of curves to complement the existing ones.
>
>Please reach out to us if this is unclear or further information is
>required.
>
>Thanks,
>
>TLS Chairs
>
>