Re: [Cfrg] Curve selection revisited

Michael Jenkins <m.jenkins.364706@gmail.com> Mon, 28 July 2014 17:17 UTC

Return-Path: <m.jenkins.364706@gmail.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 EF6501A0326 for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 10:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHOypYLounuQ for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 10:17:26 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62B01A01AA for <cfrg@irtf.org>; Mon, 28 Jul 2014 10:17:25 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id im17so11771483vcb.17 for <cfrg@irtf.org>; Mon, 28 Jul 2014 10:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.221.42.135 with SMTP id ty7mr10319010vcb.14.1406567844965; Mon, 28 Jul 2014 10:17:24 -0700 (PDT)
Received: by 10.58.6.228 with HTTP; Mon, 28 Jul 2014 10:17:24 -0700 (PDT)
In-Reply-To: <53D66506.4080809@htt-consult.com>
References: <CA+Vbu7xroa68=HOZtbf=oz7kK2EeUv_z1okpnjxHPR0ZtHD5cA@mail.gmail.com> <53D66506.4080809@htt-consult.com>
Date: Mon, 28 Jul 2014 13:17:24 -0400
Message-ID: <CAC2=hnfsZHAmnzmVAkQeKN3P1rrO+CfrJSjjWjKCb9awsrUGYA@mail.gmail.com>
From: Michael Jenkins <m.jenkins.364706@gmail.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Content-Type: multipart/alternative; boundary=001a11339974c0702504ff441884
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/lIl3DpRB4G86uVzF4xwhWcT3Fo8
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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: Mon, 28 Jul 2014 17:17:28 -0000

Bob,

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 <rgm-sec@htt-consult.com>
wrote:

> 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
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>