Re: [Cfrg] [TLS] 3DES diediedie

[Derek Atkins <[e-mail]>]

Hi,

Stephen Farrell <[e-mail]> writes:

> Hiya,
>
[snip]
>> 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.

Sure, but your definition of "good enough" and my definition of "good
enough" may not match.  And honestly I'd rather someone use 3DES than
nothing.  (Sure, I'd rather them use AES than 3DES)

[snip]
>> 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.

See, I think there are different use-cases that can (and should) be
qualified.  Many of these constrained devices may use (D)TLS, but are
still designed for a constrained environment.  They aren't going to be
connecting to my bank (although they may phone home to their
manufacturers).

My light bulb example that I keep returning to are really only designed
to speak to the local controller(s).  They don't phone home.  Sure, they
may have IPv6, and may be running (D)TLS, but their use case is rather
limited.  They probably don't have a full OS, just an embedded
firmware.

So why does this device need to same level of security protection that I
need when I'm communicating with my bank?  Wouldn't you rather it have a
lower bar (e.g. 3DES) versus have zero security?  Honestly, that's the
fight I'm fighting here with manufacturers.  They say encryption is too
expensive, so they would rather do nothing.  I'm trying to give them
something, anything, to get the bar raised.  Even single DES is better
than nothing (although if they can do 1DES they can do 3DES).

>> 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.

Keep in mind that I'm advocating assymmetric crypto and not PSK..  And
definitely not "same PSK".

> 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.

This is true.

> 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.)

So if they can't use the better algorithm (for whatever reason), what
then would you advocate?

>> 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.

See above for my re-iterated light bulb example.  I do agree that
devices are put into situations beyond what manufacturers originally
designed.  But (and I feel like I'm sounding like a broken record here)
I'd rather see devices use any crypto than no crypto.

[snip]
>> 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.

Isn't this why we're paid the big bucks?  :)

>>> 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.

Yes, this is also true. Education is important.

> Cheers,
> S.

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant