Re: [Cfrg] [TLS] 3DES diediedie

[Stephen Farrell <[e-mail]>]

Hiya,

On 07/09/16 15:32, Derek Atkins wrote:
> Hi,
> 
> Stephen Farrell <[e-mail]> writes:
> 
>> 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.
> 
> I agree completely, which is why I believe that "AES is the one true
> cipher that everything must use" is, IMHO, a Bad Idea (TM).  As Peter
> said in another email (thank you, Peter, for the GREAT writeup!!!),
> while we do want better crypto, what's more important is MORE crypto.
> We want more devices to use crypto, and if there are devices where even
> AES can't be used (for whatever reason) we should find reasonable,
> lower-"cost" alternatives.

I don't agree that we want "more crypto" without qualification.
I'd put it like this:

We want more good enough crypto and to not introduce crypto
that is not good enough. We also do want to deprecate use of
crypto no longer considered good enough, where possible.

>> 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.)
> 
> I know you're anti Simon/Speck, but there are a good dozen other
> potential symmetric LWC candidates, based on ISO specification interest
> and the NIST LWC workshop(s).
> 
>> 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.
> 
> What's your definition of "weaker" crypto?

I don't have a good definition. Perhaps we could say that
anything that we'd not want to include in TLS at a given
point in time?

That is not meant to imply there are no uses at all for
weaker crypto. But I do think the valid use-cases may be
much much rarer than many seem to think.

> 
> I'd argue that there are definitely cases where a shorter block size is
> just fine, even if it's easier to attack.  For example, if I have a
> 64-bit block size and my messages are always only a single bit
> (e.g. "door open" or "door closed"), does it matter that it's easier to
> attack than a 128-bit block size?

I don't think that's a good question tbh. The issue is that
the same algorithm will be used for other things too, e.g.
to protect new configs or s/w update or stored data. And if
we're dealing with a PSK situation, it's likely many devices
will be deployed with the same PSK. So, yes, it might matter
if there are thousands of doors and one PSK that basically
never changes. And once developers have an algorithm they
have used, they will re-use that for other things. And
attacks only ever get better. So we need to always consider
the worst case that we envisage can really happen, and not
what seems like the least sensitive interactions.

One other aspect is that we're assuming here that devices
are highly constrained, so we can't assume that they'll
use some better algorithm for more sensitive things - if
they could do that, then almost all such devices could use
the better algorithm for everything.

So while I am a big fan of opportunistic security, I'm
not keen on encompassing the use of weaker algorithms as
a part of that. (Other than for cases where the alg and
keys are already deployed and we have to live with it.)

> 
> Context is extremely important.  Obviously 64-bit blocks would be bad
> for some things, but might be "just fine" for others.  If we do say "no
> 64-bit blocks" then we get sensor manufacturers that will say "fine,
> security is too expensive so I just wont put it in".
> 
> The Perfect is the enemy of the Good Enough.

Yes, but once devices are connected to the Internet, then
the requirements for "good enough" change significantly,
and IMO that's not something that device makers have yet
properly taken on board.

> 
>> 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.
> 
> True, this will happen too.  From where I sit I'd rather give people
> better tools that might not reach our "perfect" security guidelines, but
> are cheap enough that the manufacturers will implement it instead of XOR
> (against a static "key").

Figuring out sensible guidelines that are likely to be
followed is hard, yes.

> 
>> 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;-)
> 
> I think this is the main issue -- different markets have different
> needs.  And until you're living on an 8051 or MSP430 you really don't
> understand how constrained you can be.

It's also clear that many device makers are not considering
the real threat model when their devices are exposed to the
Internet. I would argue that the choice of MCU needs to take
that much more into account than has been the case, and it's
no longer ok to only consider the functional requirements for
the application, once the device can be connected to the
Internet. That's a big change though.

Cheers,
S.


> 
>> S.
> 
> -derek
>