Re: [Cfrg] Curve selection revisited

[Robert Moskowitz <[e-mail]>]

On 07/28/2014 01:17 PM, Michael Jenkins wrote:
> 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?

Some of it is NOT internet protocols.  IEEE 1609.4 WSMP is a MAC direct 
protocol.  In 1609, it is all about broadcast messages, as every car 
needs to receive it and there is NO time for any setup. Sign the 
message, get your channel allocation and send.  There is IP for some 
stuff, but most of that is V2R (roadside).  If we tackle a proper CANbus 
(now there is an interesting non-protocol) replacement, most of it will 
be a MAC message format.  And then there is SMS.  I can keep coming up 
with cases where there is no IP (IEEE 11073), or IP only occurs at the 
gateway (pacemaker (IEEE 802.15.6) to hospital).

The lack of an Internet layer, and maybe even a transport layer with 
only a message (session) layer or just MACsec, does not mean no 
security.  Security happens at many layers other than IP (IPsec) or 
Transport (TLS, DTLS, SRTP (or is that session)).

>
>
> On Mon, Jul 28, 2014 at 10:58 AM, Robert Moskowitz 
> <[e-mail] <mailto:[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] <mailto:[e-mail]>
>     http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg