IETF Logo Mail Archive

Re: [Cfrg] Progress on curve recommendations for TLS WG

Russ Housley <housley@vigilsec.com> Thu, 31 July 2014 19:12 UTC

Return-Path: <housley@vigilsec.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 56CDA1A0048 for <cfrg@ietfa.amsl.com>; Thu, 31 Jul 2014 12:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 9iTWGMmRgPdr for <cfrg@ietfa.amsl.com>; Thu, 31 Jul 2014 12:12:26 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8CA1A003A for <cfrg@irtf.org>; Thu, 31 Jul 2014 12:12:26 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D1693F9C04C for <cfrg@irtf.org>; Thu, 31 Jul 2014 15:12:15 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id wJLdRMWWg4rV for <cfrg@irtf.org>; Thu, 31 Jul 2014 15:11:54 -0400 (EDT)
Received: from [192.168.2.108] (pool-96-255-70-16.washdc.fios.verizon.net [96.255.70.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0B84CF9C01B for <cfrg@irtf.org>; Thu, 31 Jul 2014 15:11:55 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1085)
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CFFB1371.2916E%kenny.paterson@rhul.ac.uk>
Date: Thu, 31 Jul 2014 15:11:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <15E948B3-587B-4DCB-B9F3-BCDDF46FB0E7@vigilsec.com>
References: <CFFB1371.2916E%kenny.paterson@rhul.ac.uk>
To: IRTF CFRG <cfrg@irtf.org>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/GJM_vYObdeujDzM3w9pxttTZnAU
Subject: Re: [Cfrg] Progress on curve recommendations for TLS WG
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: Thu, 31 Jul 2014 19:12:28 -0000

Kenny asked for input on five specific questions.  Here are my thoughts on the first one.

> - What is the cost of keeping backwards compatibility with existing
> defined point formats in RFC 4492, if any, for different curve shapes
> (Edwards, twisted Edwards, Montgomery, Weierstrass-only form)?

It is important to look at the use of ECC in TLS (RFC 4492), but we also need to look at PKIX since TLS will rely on certificates to bind the public key to the subject name.  RFC 5480 talks about ECC in certificates.  In my view, we should not ignore other uses of ECC in making this decision.  RFC 5753 talks about ECC for CMS; RFC 4754 talks about ECC for IKE and IKEv2; RFC 5349 talks about ECC for Kerberos PKINIT; RFC 5656 talks about ECC for Secure Shell.

For the certificate, RFC 5480 is aligned with the X9.62 specification, but the most difficult choices are not supported:
   o namedCurve -- MUST be supported.
   o implicitCurve -- MUST NOT be used.
   o specifiedCurve -- MUST NOT be used.

Since we have already limited the choice to named curves, we can simply assign names (object identifiers) to whatever curve we select.  This frees us from trying to make specify the curve using the X9.62 syntax.

For the TLS handshake, it seems to me that we can assign compatible values Supported Elliptic Curves Extension, and if necessary, for the Supported Point Formats Extension.

Russ

v2.23.0 | Report a Bug | By Email