Re: [Cfrg] Curve selection revisited

Michael Jenkins <> Mon, 28 July 2014 17:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EF6501A0326 for <>; Mon, 28 Jul 2014 10:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZHOypYLounuQ for <>; Mon, 28 Jul 2014 10:17:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C62B01A01AA for <>; Mon, 28 Jul 2014 10:17:25 -0700 (PDT)
Received: by with SMTP id im17so11771483vcb.17 for <>; Mon, 28 Jul 2014 10:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/31hY6scY2C9wVRQ3A5WWP96JsgFQvl7IJfG4yugFwY=; b=lCECI3B6RA3+yTno9txs0PG2pIFQ41B0oaJCkpsGx5jIPK3nP3xwaKTQVDkArgiA3t g2cG1mR+Wh/7JA/vExp4tEXoxg2fLQrkyc+GDAAsTMHOowIOe5n2D2nUUUfv0/nVZ6EB 2pz/4REzKsyESWykJMcRvwC3oSL7zVkF08KS36BuvNfLPBbXe0y4QhbxgQXgcxsTSCrJ rTi9CUC4yL6sJfkwFUwlr9GH27uDb0E3TD1+uOB/706tadmGtpSxRJQg10wpTED3/8K4 VZBmnrLobKlbdPq0fTocLxGPXvFQTwrhQIrQ9VhCKvvudkJ24Js6BtrIwkeXRLR1C91B 73YQ==
MIME-Version: 1.0
X-Received: by with SMTP id ty7mr10319010vcb.14.1406567844965; Mon, 28 Jul 2014 10:17:24 -0700 (PDT)
Received: by with HTTP; Mon, 28 Jul 2014 10:17:24 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 28 Jul 2014 13:17:24 -0400
Message-ID: <>
From: Michael Jenkins <>
To: Robert Moskowitz <>
Content-Type: multipart/alternative; boundary="001a11339974c0702504ff441884"
Cc: "" <>
Subject: Re: [Cfrg] Curve selection revisited
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jul 2014 17:17:28 -0000


I'm really glad to hear someone saying the whole world isn't TLS, and
IOT/constrained environments seems to be getting a lot of air-time, which
is good too. But while I was reading your email, I kept thinking, where's
the big-I Internet in this? If this is a high-speed, low-power, limited
range communication, what's the need for an Internet protocol?

On Mon, Jul 28, 2014 at 10:58 AM, Robert Moskowitz <>

> The whole world is NOT TLS.  For example I am working in IEEE 1609 which
> is Vehicle-to-vehicle safety communications and their need is for signed
> data objects that are quickly generated and verified (you have ~100ms from
> the braking event to all the cars being able to act on that information).
>  I also work in IEEE 802.15.4 highly constrained devices (some much smaller
> than what many IETF groups accept as their lower limit).
> 8 bit processors are the norm, and NO, Dr. Moore is NOT going to change
> that.  Lower energy demand is much higher on the design plan than faster
> processing.  Also whatever is done will be running on fielded devices for
> the next 10 - 20 years.  Hardware acceleration is acceptable, but that
> could make in-field corrections impossible. Over-the-air firmware updates
> may also be impossible (802.15.4k is 40kb/s) or only done in the dealership
> (yes!  another recall!).
> So getting on to my thoughts of curve selection requirements for the world
> of small:
> 1) Low over-the-air demands.  Every BIT counts.  We have to live with 32
> bytes; but 64 bytes may be too much.  Oh, IEEE 1609.2 has its own
> 'certificate' and signature format as even the standard asn.1 is too
> wasteful of the very limited channel.  This applies also in 802.15.4 where
> adding another MAC frame might mean that the whole thing fails because now
> it is more likely that one frame got lost.
> 2) Easy/size of implementation.  There has been lots of chatter here about
> how NIST p256 can be implemented wrongly.  Here it is of greater concern,
> as it might require a physical swap-out to correct an implementation error.
>  Manufacturers look at the cost of a programmer to save 5K code cheaper
> than that extra 5K footprint.  So little code and easy to code.  This world
> is extremely price sensitive.
> 3) Performance on an 8 bit  processor.  Performance is measured in time
> and energy.  In-vehicle devices tend to have a ready source of electrons
> (except for tire gauges!), but some devices have limited battery (your
> front door lock) or NO battery (MEMEs energy harvesters on bridge stress
> sensors).  So low energy is as important as quickly done.  Here 10% faster
> IS 10% faster; and it could make a life-or-death difference. (In Positive
> Train Control, the automatics MUST take over if the human can no longer
> respond in time and bullet trains can take 7Km to stop safely)
> 4) preserving ECDSA and ECDHE.  This is what is currently in use, and in
> some cases written into regulations (urgh), so we have to still keep them
> working.  But if something 'new' and provably good makes a big difference
> in one of the previous needs I suspect there will be an attentive audience.
> I have tried to keep things general so as not too much to limit choices.
>  I never claimed to be a crytographer or to have the math skills to
> evaluate the various contenders.  Others working in this area might have
> their own reading on the needs of constrained devices/communications.
> But please just don't solve this for TLS on octo-core 64-bit systems.
> On 07/25/2014 01:10 AM, Benjamin Black wrote:
>> 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.
> _______________________________________________
> Cfrg mailing list