Re: [Cfrg] [TLS] 3DES diediedie

Hi,

I'm usually immediately corrected.

But I wanted to observe that, after my recent years working in the
auto security area, there are extreme cost constraints (and power
constraints) on CPUs in small sensors and smaller auto ECUs.

Cents matter.  Dollars are out-of-the-question.

Auto product development and ISO26262 safety validation cycles
mean that today's new project will be fielded in three to five years.

FWIW, US NIST is sufficiently concerned about their perception of
the need for lightweight crypto to have created a Lightweight Crypto
project that will select multiple algorithms based on an open process.
They are currently building on previous work in ITU-T and ISO.  They
recently issued this draft report (in public review until October 31st):

http://csrc.nist.gov/publications/drafts/nistir-8114/nistir_8114_draft.pdf

One could argue "well then they won't use TLS", which may be true,
but's it's a dangerous path IMHO.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Sep 6, 2016 at 5:23 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hi Derek,
>
> On 06/09/16 21:44, Derek Atkins wrote:
> > I'm afraid I have to disagree here.  What's it's done is pushed
> > yesterday's computation capabilities into smaller and smaller devices,
> > lower and lower on the food chain.  C.f. my previous email about a light
> > bulb.  Cost is definitely a concern, as well as power and performance.
>
> I think that's true but not the entire story.
>
> Another part of the trade off is that any device that
> connects to the Internet and runs s/w is potentially
> vulnerable and usable to attack the network.
>
> So we're not only talking about security/crypto to
> protect someone's choice of what colour a bulb appears,
> but rather we're very often talking about the protection
> of a small computer on the network, and of the security
> of the network as a whole.
>
> That last I think argues strongly for support for
> sufficiently good crypto everywhere. And I'm not sure
> what sufficiently good options exist that are notably
> lighter weight than AES. (And if one does support good
> crypto then there seems less reason to use less good
> crypto for some functions.)
>
> Note that I'm arguing against weaker crypto or crypto
> of unknown or possibly-problematic provenance here. So
> I'm not arguing for HW-AES-everywhere. But it is also
> true that AES-everywhere would avoid this significant
> problem.
>
> That said, I do realise that this is not a winning
> argument as people will develop feature-rich devices
> with crap security and there's no device-police to stop
> them, but we (as in cfrg) should really also bear in
> mind that any weaker crypto anywhere has significant
> downsides as many devices really do need what we currently
> consider strong crypto because they connect to the
> Internet and may not get any updated s/w for quite some
> time.
>
> So... it's tricky - I think we know what's right but we
> also know that that's not what "the market" is going
> to produce;-)
>
> S.
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>