Re: [Cfrg] Curve selection revisited

[Michael Jenkins <[e-mail]>]

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 <[e-mail]>
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
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>