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

Benjamin Black <b@b3k.us> Fri, 18 July 2014 05:52 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 6C9B01A064E for <cfrg@ietfa.amsl.com>; Thu, 17 Jul 2014 22:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level:
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 LjZ8trTXR_fe for <cfrg@ietfa.amsl.com>; Thu, 17 Jul 2014 22:52:16 -0700 (PDT)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03B01B28EB for <cfrg@irtf.org>; Thu, 17 Jul 2014 22:52:15 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id bs8so233597wib.14 for <cfrg@irtf.org>; Thu, 17 Jul 2014 22:52:14 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TDTIELTwV4V/NweDCLS1Mbns/kFitFX3n+gmihCR/JM=; b=PTq/Vjin5OLAvkwglRxABFJzk3jVYTApz/L73QbupzcqA5snCEajrUbjAYJdM38Zor kEVR91nUKZ6lsYcJHVqmJoY/mLlA7KxXpoJTHt/g8QPsyoYZQL7md2LZuJRMqq+mTUXX gHlei3eutFS5FY8TYRlR+EersSjZfJhGkrnUxccCFPxLK/rcon6pJw26huSCHh0T2LKd xh472WfPMrDppXPe0MDGf6O+3qZSprYkaTyzGJSuiRNJAjcJkQqDv8FzJ6PXjuA/VuUP WgXbBgeRMv/X1gstbOAvNssBF7Q4guYR6nnXBkhE+Den6woSsvL52bu0KF8COpa0Pjxw 13pw==
X-Gm-Message-State: ALoCoQmJndijfhCLZ2XqqvU1y8noU9/SAWwe6VsRcDR8xL5YaX/zuAUTuMohNRxj1S4DaQzfOIul
X-Received: by 10.180.36.38 with SMTP id n6mr28367764wij.73.1405662734605; Thu, 17 Jul 2014 22:52:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.44.138 with HTTP; Thu, 17 Jul 2014 22:51:54 -0700 (PDT)
In-Reply-To: <87d2d5aspu.fsf@latte.josefsson.org>
References: <CFE9F2DE.26E5A%kenny.paterson@rhul.ac.uk> <87d2d5aspu.fsf@latte.josefsson.org>
From: Benjamin Black <b@b3k.us>
Date: Thu, 17 Jul 2014 22:51:54 -0700
Message-ID: <CA+Vbu7wG5XzP+nQX2382MvayiCw+dfXjhC-7wKjfjvG_yzUkAw@mail.gmail.com>
To: Simon Josefsson <simon@josefsson.org>
Content-Type: multipart/alternative; boundary="e89a8f502f7ef8763304fe715bf6"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/-546re5RKlvK-W6CDPVx7dN56XA
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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: Fri, 18 Jul 2014 05:52:24 -0000

"If taken literally, I believe they exclude some good candidates and steer
the selection into a rather small field of available options."

I suggest this is the nature of this process and is indicative of objective
and thorough engineering. It is often the case that the requirements
exclude all available candidate solutions, necessitating new development.
That is actually how this process started in the first place: new
requirements emerged and excluded the existing curves. Exclusion is a
feature, not a bug.

The alternative, which it seems you are suggesting, is to adjust the
requirements based not on the problem we are trying to solve but on
immediately available options that would be excluded if the requirements
were complete and adhered to in the process. In my experience that
inevitably leads to poor outcomes. In particular, in this instance we are
talking about setting a precedent for IETF adopting cryptography which has
not been standardized by any other body. We must not cut any corners on
what will be Internet cryptography for at least the next 15 years.

"I would prefer if the CFRG are at liberty to recommend the
best alternative even if it is clearly not re-usable in existing software or
standards."

See my response to Kenny a few minutes ago: the request was explicitly for
new curves, nothing more. Expanding the scope to include new algorithms
implies enormously more work on requirements, specification, and
deployment. For example, a curve which was incompatible with ECDSA would
require a new signature algorithm, which in turn would require new cipher
suites, new certificates issued by CAs from new hardware and software
platforms yet to be developed, and so on. That list doesn't even touch on
all the challenges it presents for customers of these technologies.

I share the desire to push towards more modern cryptography in IETF
specifications, but that desire is tempered by an acute awareness of the
cascade of expensive and high risk change that comes along with changing
too much too quickly. I recommend we adhere to both the letter and the
spirit of the subject line in Kenny's initial email and focus only on new
curves which are compatible with existing algorithms and protocols.


Ben



On Wed, Jul 16, 2014 at 2:39 PM, Simon Josefsson <simon@josefsson.org>
wrote:

> I'm reviewing the selection criteria.  Some of the requirements are
> rather fine-grained and poorly justified, and appear to limit the search
> space.  If taken literally, I believe they exclude some good candidates
> and steer the selection into a rather small field of available options.
>
> I'm fine with R1-R3.
>
> "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> writes:
>
> > Intellectual Property
> >
> >    R4.  Required: available worldwide under reasonable and well
> >    understood licensing terms [1]
> >
> >    R5.  Desired: available worldwide under royalty-free licensing
> >    terms [1]
>
> I believe non-royalty-free licensing terms is a nonstarter.  I suggest
> collapsing this into:
>
> R4'. Required: available for worldwide implementation (by both
>      proprietary and free open source software) and use under well
>      understood and royalty-free licensing terms
>
> > 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]
>
> I do not see why these are desirable properties, so I disagree they
> should be a selection criteria.  These properties restricts the search
> space.  I would prefer if the CFRG are at liberty to recommend the best
> alternative even if it is clearly not re-usable in existing software or
> standards.  I would go even further saying that one of the reasons for
> doing this excercise is that the existing software and standards are not
> sufficient.
>
> On the topic of interoperability, I would propose to add the following,
> to me, more important property:
>
> Rx. Desired: either a clear algorithm description exists (with clarity
> on byte-ordering etc) or multiple interoperable implementations are
> available.
>
> If some alternative does not appear to be sufficiently specified or
> widely implemented, the CFRG could take on driving a document to clarify
> the solution.
>
> > 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.)
>
> Instead of R8-R11, I suggest to summarize this more generally as:
>
> R8'. Required: the solution should be secure against reasonable and
> well-understood threats, including (but not limited to and necessarily
> not all of) brute-force, side-channel, invalid-curve, twist attacks, or
> maliciously chosen curve parameters.
>
> Designing against security threats is a balance, and I would say that
> there are no perfect solutions.  Every solution will have some area
> where they perform less well compared to some other solution.  I believe
> the overall choice(s) should reflect well-balanced alternatives with
> strong advantages and some understood disadvantages.
>
> >    R12.  Required for PAKE: indistinguishability of curve points from
> >    random strings [2]
>
> I do not see why this is a desirable property for TLS, or other IETF
> areas, so I disagree it should be a requirement.
>
> /Simon
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>