[Cfrg] Curve selection revisited

Benjamin Black <b@b3k.us> Fri, 25 July 2014 05:10 UTC

Return-Path: <b@b3k.us>
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 9C87B1A0AE9 for <cfrg@ietfa.amsl.com>; Thu, 24 Jul 2014 22:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Pjhd8Tf19Pey for <cfrg@ietfa.amsl.com>; Thu, 24 Jul 2014 22:10:40 -0700 (PDT)
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732101A0306 for <cfrg@irtf.org>; Thu, 24 Jul 2014 22:10:40 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so3707127wes.28 for <cfrg@irtf.org>; Thu, 24 Jul 2014 22:10:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Z5RXaDiY8CY1NhMkKjyLsUeyEUWdJg/UjQLEPaspckw=; b=IUvdOT3Mu/rcNV1HFonE3HE5XNxllN1yMLrW/Ew3Le51/Ud0oMB03MqSA6q4CDineL i1FhxSbXVohk+OwB9vUhtoSRXLXsu+mhVL17RfiCr0H5dKmCKZU6sXJheX9C60DzoWsY rHvsw0wYXO09E+ieXAV6RBygAM4+/FthpVcijbRkSwAeQXfl8GGot+9JC7wksSyjoh63 mUo6FC2lKqA20ROj51Xml37lmUpT/1fkzuCpucN66lFAXTe5fHKiW9qHu/mXaCigLqJZ xHeFEmqWJV37T9gXBajJbJSMuN50UZmoVGRnVvFOw8btgJjuI1bexmR0VNInwH62vl8r /Yjg==
X-Gm-Message-State: ALoCoQlH4GVsC5HtCY/3UIbLS02ZbSdJyUHOqnLEjtUTn/yrxmdET9AFAbrXYalAzpXFAyNFlRdC
X-Received: by 10.194.23.135 with SMTP id m7mr18437031wjf.2.1406265039040; Thu, 24 Jul 2014 22:10:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.44.138 with HTTP; Thu, 24 Jul 2014 22:10:18 -0700 (PDT)
From: Benjamin Black <b@b3k.us>
Date: Thu, 24 Jul 2014 22:10:18 -0700
Message-ID: <CA+Vbu7xroa68=HOZtbf=oz7kK2EeUv_z1okpnjxHPR0ZtHD5cA@mail.gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary=047d7b5d5ffe1cc64a04fefd984e
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/XLeFGjtaR1X_t_Qsi5TXBtMIdYA
Subject: [Cfrg] Curve selection revisited
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 05:10:47 -0000

Inspired by some comments from other and in hopes of returning to a more
productive debate rather than the pointed back and forth, of which I am
absolutely guilty, I'm suggesting a few constraints. These are not priority
ordered and none of them deal with the math, instead focusing on process
and practice.

1) As we are discussing this in the context of TLS, the performance of
various kx options must be evaluated for ECDHE as typically deployed. ECDH
is neither common nor recommended in the TLS BCP draft. In addition, I hope
there will be discussion of benchmarking methodology, with the
understanding the ultimate choice is for the CFRG chairs.

2) Performance must be measured using "production-quality" implementations.
By this I mean implementations which employ the sort of
techniques/optimizations appropriate for large scale deployment. This is
specifically intended to exclude discussion of how simple or fast an
implementation _could_ be, in favor of what they actually are in practice.
However, the goal is to select curves which strike the best balance between
various requirements, not simply the fastest.

3) The timeframe for a decision constrains the scope of this process. If a
decision is desired within a few months, then it is difficult to include
options beyond new curves. If a decision can take a year, new algorithms
could be considered. Given the importance, impact, and contentiousness of
new algorithms, I believe it would be difficult to complete a thorough,
careful algorithm and curve selection process in a short amount of time.

4) The precise set of security levels needed should be specified in advance
(whether by TLS or CFRG) and curve recommendations delivered together for
all levels. A stated goal is to use these curves in new drafts, and it
minimizes work to specify all security levels for a proposal in the same
draft. This is strictly a practical matter recognizing the chairs and area
directors have limited bandwidth and implementors can get everything done
in a single go.

5) Selections must efficiently support TLS 1.2. Adoption of new curves, and
potentially new algorithms, can't be gated on completion and widespread
deployment of TLS 1.3.

6) Drop-in replacement for the NIST curves is _not_ a requirement in this
process.

7) I don't think the chairs are signing up for a full-on, NIST-style
selection competition and we should aim to keep things are lightweight as
possible while still achieving the required level of rigor. I hope they
will address this point soon.


Ben