Re: [Cfrg] Curve selection revisited

[Paul Lambert <[e-mail]>]

]PS: Regarding the ASN.1 format I am wondering whether the IEEE has done
]some more detailed analysis of the over-the-wire and the software
]implementation cost. This would be useful for us in the ACE working
]group.
I know of one IEEE group that is working on raw representation of a point
for Curve25519.
In another - X.509/PKIX formats are proposed largely because they exist.

I'm partial to opaque non-ASN.1 myself.



Paul


]
]
]
]On 07/28/2014 07:05 PM, Michael Hamburg wrote:
]> You're going to need a hardware accelerator for some of these small
]> things.  Eg for v2v safety, the real ask has to be "fast and small and
]> easy in hardware".  The best solution to this is binary curves, though
]> they are considered slightly edgy right now.
]>
]> But yeah, 8-bit processor performance is important too.
]>
]> Cheers, - Mike
]>
]> On Jul 28, 2014, at 7: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
]>
]> _______________________________________________ Cfrg mailing list
]> [e-mail] http://www.irtf.org/mailman/listinfo/cfrg
]>