Re: [TLS] [Cfrg] 3DES diediedie

[Kyle Rose]

On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir  wrote:

>
> Good questions, no doubt. But I don’t think they can be answered.
>
> Someone is going to specify protocols and algorithms. This could be the
> IETF. This could be the ITU, or IEEE, or some other SDO. Makes no
> difference.
> Someone is going to implement these protocols and algorithms in some
> combination of hardware and software.
> Someone is going to combine this implementation with other parts like
> network stack, wired or wireless communications, memory to create a
> “brains” for IoT devices.
> Someone is going to build a sensor or an actuator that includes that
> “brains” plus hardware and software. This could be a lightbulb, and smoke
> detector, a temperature sensor.
> Someone is going to use this sensor or actuator as part of a system: a
> car, a refrigerator, an HVAC system, a door alarm.
> Someone is going to deploy these systems in a home, in a data center, in a
> plane, in a nuclear power plant.
>
> It’s that last step that determines how attractive this is going to be to
> attackers and what value is going to be protected by a device using these
> protocols and algorithms. And the last two steps determine how isolated the
> “thing” will be.
>

Not necessarily. Manufacturers may be able to push some of those isolation
properties higher into the list. E.g., if the silicon simply cannot speak a
more general protocol even if compromised, or has some other physical
constraint (e.g., data rate, CPU power, etc.) that limits its
expressiveness, you may be able to make provable statements about the
potential impact of compromise. We obviously can't impose those
restrictions on manufacturers, but I don't know if it's completely hopeless
to create standards or compile best practices for mitigating compromise of
insecure devices.

But this brings me back to my earlier post where I said this sounds like a
research problem: the IETF is not anywhere near being in the position of
making such recommendations. And I'm not convinced that this path is a
productive use of our time, when hardware being hardware means that
increased functionality (better crypto, upgradability) gets cheaper all the
time.

OTOH, manufacturers being manufacturers means that security and
upgradability are baked in only when users demand it, and users being users
means that no one demands either until it's too late. So it's possible
there's real value in doing the research and then creating safety standards
for classes of devices that seem to be designed to atrophy, but it's
probably more useful for that standardization to focus on network isolation
rather than on crypto since the crypto is only one small part of the TCB.

Is the era in which the marginal cost of upgradability is too expensive to
support a short one, or is this a problem we're going to be dealing with
for a long time? If the latter, then I'm starting to see some value in not
having everything be globally-routable or even talk IP.

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Yoav Nir]

> On 8 Sep 2016, at 7:08 PM, Kyle Rose  wrote:
> 
> On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann  > wrote:
> The only data point I have is that every time I've tried to disable DES in
> a new release (and by DES I mean single DES, not 3DES) I've had a chorus of
> complaints about it vanishing. 
> ... 
>  Alarms, for example, send data
> quantities measured in bytes, so some academic attack that would take 500
> million years to acquire the necessary data isn't going to lose anyone any
> sleep.  It's a nice piece of work, but you need to look at what practical
> effect it has on real, deployed systems...
> 
> To this class of examples, the problem seems to be less the implications for 
> security of the specific systems making use of weak crypto, and more the 
> effect the survival of weak options for crypto might have on other systems. 
> We don't want more general systems to be subject to attacks that may not be 
> applicable to the resource-constrained target systems, but that requires us 
> to answer a few questions about those constrained systems:
> 
> (1) Is the target system isolated, such that a compromise cannot either 
> leverage transitive trust to another system or provide an attacker a beach 
> head from which to attack (surreptitiously probe, etc.) other systems?
> 
> (2) Is the weak crypto being used by the target system in a way that renders 
> both the known and expected attacks inapplicable?

Good questions, no doubt. But I don’t think they can be answered.

Someone is going to specify protocols and algorithms. This could be the IETF. 
This could be the ITU, or IEEE, or some other SDO. Makes no difference.
Someone is going to implement these protocols and algorithms in some 
combination of hardware and software.
Someone is going to combine this implementation with other parts like network 
stack, wired or wireless communications, memory to create a “brains” for IoT 
devices.
Someone is going to build a sensor or an actuator that includes that “brains” 
plus hardware and software. This could be a lightbulb, and smoke detector, a 
temperature sensor.
Someone is going to use this sensor or actuator as part of a system: a car, a 
refrigerator, an HVAC system, a door alarm.
Someone is going to deploy these systems in a home, in a data center, in a 
plane, in a nuclear power plant. 

It’s that last step that determines how attractive this is going to be to 
attackers and what value is going to be protected by a device using these 
protocols and algorithms. And the last two steps determine how isolated the 
“thing” will be. We as an SDO are 7 steps removed from this, so we can’t make 
that determination. We can be sure that if we specify a protocol that will 
prove successful (as in adopted) by industry, that protocol will protect 
lightbulbs, but it will also end up protecting critical infrastructure, 
high-value targets and probably even lives.

We can’t even make Peter’s assumption that these things send only a few bytes 
of data, because many things send very little data. But some things will send a 
lot of data. And putting “no more than 1 MB per day” in the security 
considerations section is an exercise in futility.

Yoav


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Thu, Sep 8, 2016 at 8:01 AM, Derek Atkins  wrote:

> So they are finally up to 80-bit security?  Woohoo!
> That makes me feel so safe.
>

1024-bit RSA is certainly less than ideal, but certainly better than
nothing, which was the claim about devices in this class.

Comparisons with symmetric cryptography aren't exactly fungible like that
either: though I personally consider 1024-bit RSA keys to be weak, to my
knowledge one has not been factored successfully by the general public.

Payments are a very poor example..  Several seconds per transaction?
> That's not usable performance.  Look at all the pushback from consumers
> that have been happening since the changeover to chip cards in the US
> this past year.
>

The cryptography is not the bottleneck in this case: poor implementations
of the protocol are. Use the same card for an NFC transaction (provided
it's capable) and the delay will be considerably less.

Also, an asymmetric primitive is something you'd use to exchange keys and
sign transcripts for session initialization, after which all subsequent
communication is symmetric. Does a second of handshaking actually matter if
all subsequent communication is hardware accelerated symmetric
cryptography? (I'm sure it might for some, but won't for many others)

The real point is that if verticals within the "IoT space" were to
standardize on a particular set of asymmetric primitives and ship them en
masse like the payments industry did, economies of scale can drive the
costs down to the levels they deem acceptable. But they seem unwilling to
do the up-front development work and want to continue using the MCUs
they're already using, many of which have no crypto accelerators
whatsoever...
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Kyle Rose]

On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann 
wrote:

> The only data point I have is that every time I've tried to disable DES in
> a new release (and by DES I mean single DES, not 3DES) I've had a chorus of
> complaints about it vanishing.

...

>  Alarms, for example, send data
> quantities measured in bytes, so some academic attack that would take 500
> million years to acquire the necessary data isn't going to lose anyone any
> sleep.  It's a nice piece of work, but you need to look at what practical
> effect it has on real, deployed systems...
>

To this class of examples, the problem seems to be less the implications
for security of the specific systems making use of weak crypto, and more
the effect the survival of weak options for crypto might have on other
systems. We don't want more general systems to be subject to attacks that
may not be applicable to the resource-constrained target systems, but that
requires us to answer a few questions about those constrained systems:

(1) Is the target system isolated, such that a compromise cannot either
leverage transitive trust to another system or provide an attacker a beach
head from which to attack (surreptitiously probe, etc.) other systems?

(2) Is the weak crypto being used by the target system in a way that
renders both the known and expected attacks inapplicable?

If we can answer #1 "yes", then all a user is dealing with is a device that
might malfunction in a well-defined/delineable way upon compromise, with no
impact on other systems. It might be hard to definitively answer because,
for instance, a light bulb malfunctioning might create a safety incident if
the light bulb is a control panel indicator for some problem, so I don't
want to minimize the difficulty of coming to a "yes" answer here.

If the answer to #1 is "no" or is too difficult to answer, however, then we
have to actually analyze the weaknesses in the crypto with respect to how
the device could be used.

Where I'm going with this is that #1 is going to be particularly difficult
to answer if the protocol making use of the weak crypto is TLS and the
device is connected to the internet, simply because the potential for
complex interactions is so high. The safest course may be to continue to
deprecate weak crypto for TLS, IPsec, etc. under the assumption that the
systems making use of those protocols are both powerful enough and
well-connected enough to cause a problem if compromised. Nothing stops
resource-constrained systems from continuing to use old implementations of
TLS that do support weak crypto, though I question the wisdom of producing
parts with no upgrade path that speak such a complex, general transport
protocol rather than something naturally 0-RTT in the steady state that
would use less CPU and power, have a smaller TCB, and not rely on an ASN.1
implementation for domain isolation (e.g., Kerberos).

Which leads directly into the issue of the potential for implementation
vulnerabilities, something that is probably even more likely to lead to
loss of control than weak crypto, and which may ultimately force users to
demand IoT devices for which the answer to #1 is always "yes". So I wonder
if all the worrying about weak crypto is just a red herring compared with
the exploits we are actually going to encounter.

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

Peter Gutmann  writes:

> Richard Hartmann  writes:
>
>>Is it correct when I say that the embedded programmers you talked to don't 
>>care about any form of DES as they need/must/prefer to do AES, anyway?
>
> The only data point I have is that every time I've tried to disable DES in
> a new release (and by DES I mean single DES, not 3DES) I've had a chorus of 
> complaints about it vanishing.  Unfortunately I don't have anything more
> than that, you only find out about things like this when they break stuff.
> Certainly DES still sees a surprising amount of use, and in many cases it's
> quite justified, whatever you're protecting is adequately safeguarded with
> DES.  For example burglar alarms, if they use real encryption (far too many
> use "encryption" that would more accurately be described as data masking),
> often use DES, no doubt based on Microchip App Note 583 or freely available
> source like despiccable, which runs in 20 bytes of RAM (if your burglar alarm
> is advertised as having a "RISC based CPU" then it's probably using a PIC,
> having a processor so spartan it can barely add is now a marketing feature if
> you use the right name for it).  They'll be using DES forever, because the 
> entire environment they operate in runs DES.
>
>>If yes, there's no reason in the embedded world that would prevent a 
>>diediedie.
>
> See above.  You're not going to get rid of DES.  And, as I've pointed out
> earlier, the embedded world won't even know your diediedie exists, and if
> it's pointed out to them they'll ignore it.  Alarms, for example, send data
> quantities measured in bytes, so some academic attack that would take 500 
> million years to acquire the necessary data isn't going to lose anyone any 
> sleep.  It's a nice piece of work, but you need to look at what practical 
> effect it has on real, deployed systems...

EXACTLY!

> Peter.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

Tony Arcieri  writes:

> On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann 
> wrote:
>
> When crypto hardware support is available, it's universally AES,
> occasionally
> SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA 
>
> EMV chip cards support RSA digital signatures. Granted earlier EMV cards used
> ridiculously small key lengths (i.e. 320-bits), but they have been gradually
> ratcheted up to e.g. 768 or 1024-bits.

So they are finally up to 80-bit security?  Woohoo!
That makes me feel so safe.

> These cards number in the billions (10s of billions?) and the chips are priced
> in the penny range.
>
> I don't think it's impractical to ship hardware accelerated asymmetric crypto
> primitives on chips that meet the specifications you're describing. The
> payments industry has definitely shown it's possible.

Payments are a very poor example..  Several seconds per transaction?
That's not usable performance.  Look at all the pushback from consumers
that have been happening since the changeover to chip cards in the US
this past year.

> Tony Arcieri

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

Richard Hartmann  writes:

>Is it correct when I say that the embedded programmers you talked to don't 
>care about any form of DES as they need/must/prefer to do AES, anyway?

The only data point I have is that every time I've tried to disable DES in
a new release (and by DES I mean single DES, not 3DES) I've had a chorus of 
complaints about it vanishing.  Unfortunately I don't have anything more
than that, you only find out about things like this when they break stuff.
Certainly DES still sees a surprising amount of use, and in many cases it's
quite justified, whatever you're protecting is adequately safeguarded with
DES.  For example burglar alarms, if they use real encryption (far too many
use "encryption" that would more accurately be described as data masking),
often use DES, no doubt based on Microchip App Note 583 or freely available
source like despiccable, which runs in 20 bytes of RAM (if your burglar alarm
is advertised as having a "RISC based CPU" then it's probably using a PIC,
having a processor so spartan it can barely add is now a marketing feature if
you use the right name for it).  They'll be using DES forever, because the 
entire environment they operate in runs DES.

>If yes, there's no reason in the embedded world that would prevent a 
>diediedie.

See above.  You're not going to get rid of DES.  And, as I've pointed out
earlier, the embedded world won't even know your diediedie exists, and if
it's pointed out to them they'll ignore it.  Alarms, for example, send data
quantities measured in bytes, so some academic attack that would take 500 
million years to acquire the necessary data isn't going to lose anyone any 
sleep.  It's a nice piece of work, but you need to look at what practical 
effect it has on real, deployed systems...

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann 
wrote:

> When crypto hardware support is available, it's universally AES,
> occasionally
> SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA


EMV chip cards support RSA digital signatures. Granted earlier EMV cards
used ridiculously small key lengths (i.e. 320-bits), but they have been
gradually ratcheted up to e.g. 768 or 1024-bits.

These cards number in the billions (10s of billions?) and the chips are
priced in the penny range.

I don't think it's impractical to ship hardware accelerated asymmetric
crypto primitives on chips that meet the specifications you're describing.
The payments industry has definitely shown it's possible.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Salz, Rich]

Perhaps a way forward here is for someone to document a target platform.  Or 
multiple target platforms, and decide which are in-scope and out of scope for 
us to look at.

Arguing by anecdote -- this lightbulb has this 10-cent part, that car has this 
ARM supercore with gigs of memory -- just gets us going around and around in 
circles.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

Ilari Liusvaara  writes:

>The TLS-style asymmetric designs don't come even close to cutting it if
>client lacks good entropy source.

Actually they're fine, see the comment about using entropy from both sides.
You can run one side of a TLS communication with zero entropy (just a fixed
secret) if you mix the client and server hello into your PRNG alongside the
fixed secret data.

>Heck, I have seen board advertised for "IoT" applications where the way I
>loaded new software was to transfer the C++11 source via either USB stick or
>via TCP/IP over ethernet and then use GCC on the board itself to make a
>binary...

That's how you do development work for the CI20.  It's actually rather
convenient, you just plug it in, SSH over, and you're ready to go.

Maybe that's one way to identify whether your "IoT device" falls into the
desktop-PC equivalent class, if it can self-host its own build tools it's a
PC.  If you upload a single solid blob that's the BSP/OS and application all
in one over a serial port and debug it using whatever cavemen used to debug
fire then it's embedded/IoT/SCADA/whatever.

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Richard Hartmann]

On Wed, Sep 7, 2016 at 6:15 AM, Peter Gutmann  wrote:
> [a lot of really interesting stuff]

Thanks for the write-up. To focus what you wrote back on the thread at hand:

Is it correct when I say that the embedded programmers you talked to
don't care about any form of DES as they need/must/prefer to do AES,
anyway?

If yes, there's no reason in the embedded world that would prevent a diediedie.


Richard

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Ilari Liusvaara]

On Wed, Sep 07, 2016 at 04:15:05AM +, Peter Gutmann wrote:

> Firmware is never updated, and frequently *can* never be updated.  This is
> typically because it's not writeable, or there's no room (the code already
> occupies 120% of available storage, brought down to 100% by replacing the
> certificate-handling code with a memcpy() for encoding and a seek + read of {
> n, e } for decoding, see below), leaving 0% available for firmware updates.
> Alternatively, there's no connectivity to anything to provide updates, either
> of firmware or anything else (for example in one globally-deployed system the
> CRL arrives once every 6-12 months via sneakernet, although I'm not sure why
> they use CRLs since they can just disable the certificate or device
> centrally).  Or the device, once approved and operational, can't ever be
> changed.  Like children, make one mistake here and you have to live with it
> for the next 15-20 years.

So one needs to do _really_ careful design (good luck with that, most
device design is utter garbage).

And also really careful implementation (good luck with that too).

Also, with 20 year time horizon from now, quantum computing is a serious
risk. Mostly concerns use of any asymmetric algorithms, since symmetric
algorithms should survive rather well[1].

> The device may have no or only inadequate entropy sources.  Alternatively, if
> there is an entropy source, it may lose state when it's powered off (see the
> earlier comment on power management), requiring it to perform a time-consuming
> entropy collection step before it can be used.  Since this can trigger the
> watchdog (see the comment further down), it'll end up not being used.  Any
> crypto protocol should therefore allow the entropy used in it to be injected
> by both parties like TLS' client and server random values, because one party
> may not have any entropy to inject.  In addition, it's best to prefer
> algorithms that aren't dependent on high-quality randomness (ECDSA is a prime
> example of something that fails catastrophically when there are problems with
> randomness).

Lack of entropy is going to make things nasty. Especially with any sort of
asymmetric encryption or key exchange.

The TLS-style asymmetric designs don't come even close to cutting it if
client lacks good entropy source.

> As mentioned previously, certificates are handled by memcpy()ing a pre-encoded
> certificate blob to the output and seeking to the appropriate location in an
> incoming certificate and extracting { n, e } (note that that's { n, e }, not 
> { p, q, g, y } or { p, a, b, G, n, ... }).  If you've ever wondered why you
> can feed a device an expired, digital-signature-only certificate and use it
> for encryption, this is why (but see also the point on error handling below).
> This is precisely what you get when you take a hardware spec targeted at
> Cortex M0s, Coldfire's, AVRs, and MSP430s, and write a security spec that
> requires the use of a PKI.

Use of PKI in many cases is just dumb idea, and even if you have case
where you need some form of PKI, X.509 is probably a bad idea to do it.
 
> Hardware-wise, a Raspberry Pi is a desktop PC, not an embedded device.  So is
> an Alix APU, a BeagleBoard, a SheevaPlug, a CI20, a CubieBoard, a C.H.I.P, and
> any number of similar things that people like to cite as examples of IoT
> devices.

Heck, I have seen board advertised for "IoT" applications where the
way I loaded new software was to transfer the C++11 source via either
USB stick or via TCP/IP over ethernet and then use GCC on the board
itself to make a binary...

Basically, if one can do that at all, it is pretty much sky is the limit
with the crypto...
 
> Development will be done by embedded systems engineers who are good at making
> things work in tough environments but aren't crypto experts.  In addition,
> portions of the device won't always work as they should.  Any crypto used had
> better be able to take a huge amount of of abuse without failing.  AES-CBC,
> even in the worst-case scenario of a constant, all-zero IV, at worst degrades
> to AES-ECB.  AES-GCM (and related modes like AES-CTR), on the other hand, fail
> completely for both confidentiality and integrity protection.  And you don't
> even want to think about all the ways ECDSA can fail (see, for example, the
> issues with entropy, and timing issues, above).

If you need symmetric encryption that can actually take abuse, you need
MRAE (heck, the M and R is pretty much synonym for can cope with serious
abuse).


[1] Even the algorithms that would have sub-par "security levels" are
likely formidable challenge to attack, even with quantum computer, due
to make-or-break-attack factors ignored by such simplistic analysis.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Joachim Strömbergson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Aloha!

Derek Atkins wrote:
> Because this is a light bulb that sells for $6-10.  Adding $2 to the
> price is just completely unreasonable.  The price point needs to be
> pennies. Note that this is just one example, but yes, these level of
> products are getting "smarter" and we, as security professionals,
> should encourage "as strong security as possble" without getting the
> manufacturers to just say "sorry, too expensive, I'll go without."
> (which is, unfortunately, exactly what's been happening)

There are connected light bulbs and LEDs that contains ARM based MCUs on
the market today. Those MCUs costs less then 10 cents in high volume.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.

 Joachim Strömbergson  Secworks AB  joac...@secworks.se

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJXz72YAAoJEF3cfFQkIuyNkTMP/ixcCRpt4e5BlVvKqWbeXzjo
Rv3OPqnnezPwUb823g2ODWGzbumc2kD9buREtTF1fr87T+bH77vS5SATsY62M2PL
DFYbRCzV5IED5RXgO8YqiyHQJMCeMVmDmrlIEFWqEWkM6V2tlj9vLRKW0EuCdXAa
GhnVDr3Qn7hchkxE/MWlUQiG6sTsC7KSofCsW2TNKQ0rVbovcS14VC99eul4mxk/
1SVBMPdWbejyB5gBZ3r2brFEeRfDrJL2YLYJlU9aIanY4ZT3hNLlIWAgp4hLwLFw
VPQkjby7zuLS53RZ2wOvQxdwl2poNX3KgrMqFxJnd06FWE4GhMVRXDyeu+sAzYpD
bpsVvWpxfjbRYsh9PLCelqwuuhUyVJpcjuJeXBNkV1rqPbpQ6cA9yMARE3um3EAa
qUx3gp0uMryqRmBLWNsqHvQAD4OpQqgS8pT4HTRuRKmZggtHKMObqUcBtUcIrJx+
VyFVwsDhgkeHD56SKN/hywjwPV4dZHnJGPUSXPwXa5rU21vjFCNInAm/+MQBAtEV
7XUDi2ejdTykuQpcs6QuZyKpXzEn5hbtN1b3lM35AJUIex1srPhUUcojU9GH02NT
l/7qMQH40qybEB+DPaTSMW1jT6niyWVLtaQHEwJPR+xNTzJRyNc68ZWs/c6zvMCC
rKcczay2SEf4EWLER2Yt
=P0FV
-END PGP SIGNATURE-

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

OK, so I said I'd get some notes on the environment within which IoT crypto
has to function, here's what the peanut gallery came up with.  A lot of this
isn't my own work and I don't claim it to be, it's a collaboration created by
people who for various business/legal reasons can't attach their names to
public comments.  Note that every one of the for-instances given below are
actual real-life examples, not something someone invented to make a good
story.

Peter.

IoT Crypto, What you Need to Know
-

  The problem we have is not how to get stronger crypto in place, it's how to
  get more crypto in place.
-- Ian Grigg, 28 August 2016.

  ... and to raise the level of security of the rest of the system so that
  attackers are actually forced to target the crypto rather than just
  strolling around it.
-- Peter Gutmann, in corollary.

The device may be operating under severe power constraints.  There are IoT
devices that need to run for several years on a single battery pack.  If
you're lucky, it's a bundle of 18650s.  If you're less lucky, it's a CR2032.

Renegotiating protocol state on every wake event is incompatible with low
power consumption.  The crypto should be able to resume from a pause an
arbitrary amount of time later.

Even if the device is constantly powered, many components will be powered only
when needed, and will lose state when powered off (they work by warm-starting
very quickly rather than saving state across restarts).

Some IoT chips can't cost more than a few cents each.  If you're lucky,
they're allowed to cost tens of cents.  Any fancy crypto hardware will break
the budget.

When crypto hardware support is available, it's universally AES, occasionally
SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA (there are also
oddballs like ones that do SHA-1 but not AES, but they're pretty special
cases, and AES in software is very efficient in any case).  Any crypto had
therefore better be based mostly, or exclusively, around AES.  As a convenient
side-effect of this, you won't have to worry about which flavour of PKC will
be in fashion in ten years' time, or what keysize they're wearing in Paris
that year.

Even if the device includes crypto hardware, the HAL or vendor-supplied
firmware may not make it available.  In addition the crypto engine will be in
a separate IP core that's effectively an external peripheral, and accessing it
is so painful that it's quicker to do it in software (you never get AES
instructions, you get something that you talk to via PIO).  As a result you
have to run your crypto in software while the crypto hardware sits idle.

Devices have a design lifetime of ten to twenty years, possibly more.  There
is hardware deployed today that was designed when the people now maintaining
it were in kindergarten.

Firmware is never updated, and frequently *can* never be updated.  This is
typically because it's not writeable, or there's no room (the code already
occupies 120% of available storage, brought down to 100% by replacing the
certificate-handling code with a memcpy() for encoding and a seek + read of {
n, e } for decoding, see below), leaving 0% available for firmware updates.
Alternatively, there's no connectivity to anything to provide updates, either
of firmware or anything else (for example in one globally-deployed system the
CRL arrives once every 6-12 months via sneakernet, although I'm not sure why
they use CRLs since they can just disable the certificate or device
centrally).  Or the device, once approved and operational, can't ever be
changed.  Like children, make one mistake here and you have to live with it
for the next 15-20 years.

Even if the hardware and/or firmware could be updated, the rest of the
infrastructure often can't.  Some firmware needs to be built with a guaranteed
correspondence between the source code and the binary.  This means not only
using approved compilers from the late 1990s that cleanly translate the code
without using any tricks or fancy optimisations, but also scouring eBay for
the appropriate late-1990s hardware because it's not guaranteed that the
compiler running on current CPUs will produce the same result.

Don't bother asking "have you thought about using $shiny_new_thing from
$vendor" (or its closely-related overgeneralisation "Moore's Law means that
real soon now infinite CPU/memory/crypto will be available to anyone for
free").  They're already aware of $shiny_new_thing, $shiny_other_thing, and
$shiny_thing_you_havent_even_heard_of_yet, but aren't about to redo their
entire hardware design, software toolchain, BSP, system firmware,
certification, licensing, and product roadmap for any of them, no matter how
shiny they are.

The device may have no or only inadequate entropy sources.  Alternatively, if
there is an entropy source, it may lose state when it's powered off (see the
earlier comment on power management), requiring it to perform a time-consuming
entropy collection 

Re: [TLS] [Cfrg] 3DES diediedie

[Philip Levis]

The market is moving to ARM Cortex Ms, in part because of their clean I/O 
architecture and good SoC support. An M0 with integrated BLE chipset is easily 
<1$ today at small scale. Extrapolate a few years and to volume of millions 
between large companies rather than small startups.  Software like mBed OS and 
6lowpan support helps too. 

You or I might not want chips in our light bulbs, but some people will, and so 
it is part of the Internet landscape we need to keep in mind. 

Phil [sent from a phone]

> On Sep 6, 2016, at 5:17 PM, Dave Garrett  wrote:
> 
>> On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote:
>> Ben Laurie  writes:
>>>An ARM is far too much hardware to throw at "read sensor/munge data/send
>>>data".
>>> 
>>> The question is not "how much hardware?" but "price?" - with  ARMs 
>>> including h
>>> /w AES coming in at $2 for a single unit, its hard to explain why you\d want
>>> to use a less powerful CPU...
>> 
>> Because this is a light bulb that sells for $6-10.  Adding $2 to the price
>> is just completely unreasonable.  The price point needs to be pennies.
>> Note that this is just one example, but yes, these level of products are
>> getting "smarter" and we, as security professionals, should encourage
>> "as strong security as possble" without getting the manufacturers to
>> just say "sorry, too expensive, I'll go without."  (which is,
>> unfortunately, exactly what's been happening)
> 
> Personally, I'd just say "stop putting chips in light bulbs", instead. 
> Companies making these things are unfortunately just not going to be making 
> good security decisions. Bad or no security is cheaper than competent 
> security, and selling light bulbs with bad security is not illegal. We'll be 
> more successful focusing our effort on dealing with light bulb botnets than 
> trying to get people to make secure "smart" light bulbs. There is no good 
> solution on our end, and debating the price of chips for light bulbs is not a 
> good way to make security decisions in TLS.
> 
> 
> Dave
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Ira McDonald]

Hi Dave,

Might work for lightbulbs.  Doesn't work for automotive sensors and ECUs,
which already have proprietary security (undisclosed algorithms) and badly
need to have standards-based security.  Cents in cost really matter here.
ARM CPUs are not and will not become the only answer in automotive.

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: blueroofmu...@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 8:17 PM, Dave Garrett  wrote:

> On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote:
> > Ben Laurie  writes:
> > > An ARM is far too much hardware to throw at "read sensor/munge
> data/send
> > > data".
> > >
> > > The question is not "how much hardware?" but "price?" - with  ARMs
> including h
> > > /w AES coming in at $2 for a single unit, its hard to explain why
> you\d want
> > > to use a less powerful CPU...
> >
> > Because this is a light bulb that sells for $6-10.  Adding $2 to the
> price
> > is just completely unreasonable.  The price point needs to be pennies.
> > Note that this is just one example, but yes, these level of products are
> > getting "smarter" and we, as security professionals, should encourage
> > "as strong security as possble" without getting the manufacturers to
> > just say "sorry, too expensive, I'll go without."  (which is,
> > unfortunately, exactly what's been happening)
>
> Personally, I'd just say "stop putting chips in light bulbs", instead.
> Companies making these things are unfortunately just not going to be making
> good security decisions. Bad or no security is cheaper than competent
> security, and selling light bulbs with bad security is not illegal. We'll
> be more successful focusing our effort on dealing with light bulb botnets
> than trying to get people to make secure "smart" light bulbs. There is no
> good solution on our end, and debating the price of chips for light bulbs
> is not a good way to make security decisions in TLS.
>
>
> Dave
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Dave Garrett]

On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote:
> Ben Laurie  writes:
> > An ARM is far too much hardware to throw at "read sensor/munge data/send
> > data".
> >
> > The question is not "how much hardware?" but "price?" - with  ARMs 
> > including h
> > /w AES coming in at $2 for a single unit, its hard to explain why you\d want
> > to use a less powerful CPU...
> 
> Because this is a light bulb that sells for $6-10.  Adding $2 to the price
> is just completely unreasonable.  The price point needs to be pennies.
> Note that this is just one example, but yes, these level of products are
> getting "smarter" and we, as security professionals, should encourage
> "as strong security as possble" without getting the manufacturers to
> just say "sorry, too expensive, I'll go without."  (which is,
> unfortunately, exactly what's been happening)

Personally, I'd just say "stop putting chips in light bulbs", instead. 
Companies making these things are unfortunately just not going to be making 
good security decisions. Bad or no security is cheaper than competent security, 
and selling light bulbs with bad security is not illegal. We'll be more 
successful focusing our effort on dealing with light bulb botnets than trying 
to get people to make secure "smart" light bulbs. There is no good solution on 
our end, and debating the price of chips for light bulbs is not a good way to 
make security decisions in TLS.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

Ben Laurie  writes:

> An ARM is far too much hardware to throw at "read sensor/munge data/send
> data".
>
> The question is not "how much hardware?" but "price?" - with  ARMs including h
> /w AES coming in at $2 for a single unit, its hard to explain why you\d want
> to use a less powerful CPU...

Because this is a light bulb that sells for $6-10.  Adding $2 to the price
is just completely unreasonable.  The price point needs to be pennies.
Note that this is just one example, but yes, these level of products are
getting "smarter" and we, as security professionals, should encourage
"as strong security as possble" without getting the manufacturers to
just say "sorry, too expensive, I'll go without."  (which is,
unfortunately, exactly what's been happening)

> Hilarie

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  On 31 August 2016 at 20:48, Hilarie Orman  wrote:

>  > >  From: Brian Sniffen 
>  >
>  > >  >>  From: Derek Atkins 
>  > >  >>  Date: Wed, 31 Aug 2016 10:17:25 -0400
>  > >  >
>  > >  >>  "Steven M. Bellovin"  writes:
>  > >  >
>  > >  >>  > Yes.  To a large extent, the "IoT devices are too puny for real
>  > >  >>  > crypto" is a hangover from several years ago. It was once true;
>  > for
>  > >  >>  > the most part, it isn't today, but people haven't flushed their
>  > cache
>  > >  >>  > from the old received wisdom.
>  > >  >
>  > >  >>  This is certainly true for AES, mostly because many small chips are
>  > >  >>  including AES accelerators in hardware.  It's not quite true for
>  > public
>  > >  >>  key solutions; there are still very small devices where even ECC
>  > takes
>  > >  >>  too long (and yes, there are cases where 200-400ms is still too
>  > long).
>  > >  >
>  > >  >>  > It pays to look again at David Wagner's slides from 2005, on
>  > sensor
>  > >  >>  > nets and crypto:
>  > >  >>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  > >  >>  >
>  > >  >
>  > >  > Unattended sensors with wifi present an unsolved crypto problem.  They
>  > >  > can last 10 years on an AA battery without crypto, probably well less
>  > >  > than a year if they have to do any kind of encryption.  These things
>  > >  > will be everywhere, providing the data that will underly all kinds of
>  > >  > decision-making.
>  >
>  > >  Assuming there are *some* integrity requirements for the data, and that
>  > >  they are deploying 32-bit ARM with AES support (stipulating that ~every
>  > >  CPU will have AES support in a few years, as ~every CPU sold does
>  > >  today), we're talking about *either* an ECDHE negotiation every few
>  > >  months or a pre-shared key, good for ten years.
>  >
>  > >  AES-GCM with hardware support compares favorably to SHA-2 without
>  > >  hardware support, so if they've been able to last 10 years before, they
>  > >  should do just fine in the future.  The old devices won't last forever,
>  > >  and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
>  > >  for ten years after 1.3 is out.
>  >
>  > >  -Brian
>  >
>  > >  > Although much of the solution may lie in hardware innovation, the
>  > >  > world really does need minimal crypto algorithms.
>  > >  >
>  > >  > Hilarie
>  > >  >
>  >
>  > An ARM is far too much hardware to throw at "read sensor/munge data/send
>  > data".
>  >

>  The question is not "how much hardware?" but "price?" - with  ARMs
>  including h/w AES coming in at $2 for a single unit, its hard to explain
>  why you\d want to use a less powerful CPU...


>  >
>  > Hilarie
>  >

Power.

Hilarie

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

"Steven M. Bellovin"  writes:

> On 31 Aug 2016, at 10:17, Derek Atkins wrote:
>
>> "Steven M. Bellovin"  writes:
>>
>>> Yes.  To a large extent, the "IoT devices are too puny for real
>>> crypto" is a hangover from several years ago. It was once true; for
>>> the most part, it isn't today, but people haven't flushed their cache
>>> from the old received wisdom.
>>
>> This is certainly true for AES, mostly because many small chips are
>> including AES accelerators in hardware.  It's not quite true for public
>> key solutions; there are still very small devices where even ECC takes
>> too long (and yes, there are cases where 200-400ms is still too long).
>>
> Certainly plausible.  What I'm saying is (a) don't assert, measure; and
> (b) measure again next year because tech keeps improving.
>
> As for your specific points: if AES is indeed feasible, we don't need
> new ciphers.

It is feasible in many cases.  It may not be feasible in all cases.

> If elliptic curve is too slow, the only answer is architectures
> that don't use public key at all; we're not going to find new, cheaper
> public key algorithms without a *lot* of effort and the people who can
> do that sort of thing are too busy working on post-quantum crypto.

Nothing says these two aren't the same problem ;)

> The remaining approach is a cheaper protocol than TLS.  That shouldn't
> be hard at all, especially if we're going back to KDCs.

True.

> --Steve Bellovin, https://www.cs.columbia.edu/~smb

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Kyle Rose]

On Mon, Aug 29, 2016 at 5:00 AM, Hubert Kario  wrote:

>
> we have enough problems weeding out implementation mistakes in TLS, we
> don't
> need yet another protocol and two dozen implementations that come with it
>

Strongly agreed.

Focusing energy on getting "something" working for low-power devices is
putting the cart before the horse. Security has to be a primary objective
here, in the standards world in general and in CFRG in particular. We can
surely consider tradeoffs---more frequent key rotations, security
guarantees reduced in a well-defined way, shorter lifetimes for
credentials, etc.---but these should be explicitly chosen, not determined
after the fact based on what happened to be in our toolbox at the time.
Keeping 3DES around in a general-purpose protocol headed for
standardization in spite of the known problems with small block sizes is
almost certain to create more work in the coming years for everyone simply
to benefit implementors of systems for which security is clearly not the
primary concern.

>From following the discussion, low power crypto seems like a research area
at this point, not an implementation effort. (Of course, the flaws in
whatever ill-advised schemes get implemented will generate their own
research efforts and inevitable transitive trust problems with supposedly
more-secure systems. Alas, we haven't yet figured out a way to keep people
from generating sufficient rope to hang themselves with.)

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

joac...@secworks.se writes:

>  Aloha!

Aloha auinala.

>  Hilarie Orman wrote:
>  > An ARM is far too much hardware to throw at "read sensor/munge
>  > data/send data".

>  No, they are not. The Cortex M0+ is aimed at these kinds of very simple
>  systems that runs for many years on a single battery.

>  Look at the STM32L0 series from ST for example. These devices can run on
>  energy harvesting and very tiny physically and very, very cheap (ten-ish
>  cents in high volume):

>  
> http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html?querycriteria=productId=SS1817

>  The STM32L021 has an AES-128 core. Not very fast (200+ cycles), but
>  several times faster than SW. You can also run the AES core wile the CPU
>  core is in power save mode.

>  Another example is the Zero Gecko from Silicon Labs. Same price range, a
>  huge number of power modes. And an AES core that is really fast. 50+
>  cycles for AES-128, which basically means 4 cycles/round (which implies
>  4 S-boxes)

>  
> https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx

For devices you refer to, how many AES blocks can they encrypt on a AA
battery, assuming that the usage is to encrypt one block every 10 minutes?

Hilarie

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Joachim Strömbergson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Aloha!

Hilarie Orman wrote:
> An ARM is far too much hardware to throw at "read sensor/munge
> data/send data".

No, they are not. The Cortex M0+ is aimed at these kinds of very simple
systems that runs for many years on a single battery.

Look at the STM32L0 series from ST for example. These devices can run on
energy harvesting and very tiny physically and very, very cheap (ten-ish
cents in high volume):

http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html?querycriteria=productId=SS1817

The STM32L021 has an AES-128 core. Not very fast (200+ cycles), but
several times faster than SW. You can also run the AES core wile the CPU
core is in power save mode.

Another example is the Zero Gecko from Silicon Labs. Same price range, a
huge number of power modes. And an AES core that is really fast. 50+
cycles for AES-128, which basically means 4 cycles/round (which implies
4 S-boxes)

https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx

Pre-shared key is whats easiest. But I've implemented Curve25519 for key
exchange on the STM32 device and can achieve <1 sec performance with
about 1 kByte RAM and 8 kByte code. I'm sure Peter Schwabe has some much
better results.


Yes, you can limit yourself to an 8-bit MCU and shave off some cents and
a little bit of power. But for most applications I see, a Cortex M0+
meets technical and commercial requirements too.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.

 Joachim Strömbergson  Secworks AB  joac...@secworks.se

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJXx923AAoJEF3cfFQkIuyN4tkP+QGscSmBzUAPbamlaRqpm7sh
zVwhMwhllJMdTs+HozeSbMvtw7JlO5vu+PyD/El4sxP2SAQhv1LqJFaC0nxuCJ2P
I+RxISEkrxYYB2YDRGlPd3Cfm4cRrDBd/BQCPMZuAQurWxH7ptMMKIZ3hS6NuOIb
gyluKMDMrUW9qFx0lrpa3yAMPHrBqlhHl1GmcUMJwoRVGOxDdc243YjNB7J/FEDh
pJCzI8Dv4uyWEufr0cBv1xCiSY4eaalv25H/Cyc3rZ78Os7d52DUyuBD8IAuAkkH
i32L2gK7CbrCF/3zw+Tv2aDn1ncGOiucENmQIzO99hwWwtJFC7TN59rCtoArmh5U
EC0Ncq1IIbicrot+DLibHNvSWk0c15bvtg1c06UecME21SF2t8ZigF0OuYKGdeu1
a4h0dUcNUyQxUbAs9JDTXtwABvR7CMNZi3kD5Vh8NfvK7DmojPVThrQ1r/2x+6hS
QnPiZcuvedjkM19y1hRchZQT23qPJQ4TrC5MvQSHnU20oW3QomPJfTAXtCctsN5s
3b+ZdWh5/EAysPpgjzzwKP0mWN3tkeSKROsh6BabMku84zerKPzCn5MwhyhUqHLD
Sv453a5oK0ne5pD/b7CIPWRwK2Z6/6pFN+jWPG0SZtZTgEJjkSVPaskMd51SVSga
EkqJv7VnqIa5lP5es+Is
=ri48
-END PGP SIGNATURE-

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

On Wed, August 31, 2016 3:48 pm, Hilarie Orman wrote:

>
> An ARM is far too much hardware to throw at "read sensor/munge data/send
> data".

What about an 8051?

> Hilarie

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  From: Brian Sniffen 

>  >>  From: Derek Atkins 
>  >>  Date: Wed, 31 Aug 2016 10:17:25 -0400
>  >
>  >>  "Steven M. Bellovin"  writes:
>  >
>  >>  > Yes.  To a large extent, the "IoT devices are too puny for real
>  >>  > crypto" is a hangover from several years ago. It was once true; for
>  >>  > the most part, it isn't today, but people haven't flushed their cache
>  >>  > from the old received wisdom.
>  >
>  >>  This is certainly true for AES, mostly because many small chips are
>  >>  including AES accelerators in hardware.  It's not quite true for public
>  >>  key solutions; there are still very small devices where even ECC takes
>  >>  too long (and yes, there are cases where 200-400ms is still too long).
>  >
>  >>  > It pays to look again at David Wagner's slides from 2005, on sensor
>  >>  > nets and crypto:
>  >>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  >>  >
>  >
>  > Unattended sensors with wifi present an unsolved crypto problem.  They
>  > can last 10 years on an AA battery without crypto, probably well less
>  > than a year if they have to do any kind of encryption.  These things
>  > will be everywhere, providing the data that will underly all kinds of
>  > decision-making.

>  Assuming there are *some* integrity requirements for the data, and that
>  they are deploying 32-bit ARM with AES support (stipulating that ~every
>  CPU will have AES support in a few years, as ~every CPU sold does
>  today), we're talking about *either* an ECDHE negotiation every few
>  months or a pre-shared key, good for ten years.

>  AES-GCM with hardware support compares favorably to SHA-2 without
>  hardware support, so if they've been able to last 10 years before, they
>  should do just fine in the future.  The old devices won't last forever,
>  and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
>  for ten years after 1.3 is out.

>  -Brian

>  > Although much of the solution may lie in hardware innovation, the
>  > world really does need minimal crypto algorithms.
>  >
>  > Hilarie
>  >

An ARM is far too much hardware to throw at "read sensor/munge data/send data".

Hilarie

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Brian Sniffen]

Hilarie Orman  writes:

>>  From: Derek Atkins 
>>  Date: Wed, 31 Aug 2016 10:17:25 -0400
>
>>  "Steven M. Bellovin"  writes:
>
>>  > Yes.  To a large extent, the "IoT devices are too puny for real
>>  > crypto" is a hangover from several years ago. It was once true; for
>>  > the most part, it isn't today, but people haven't flushed their cache
>>  > from the old received wisdom.
>
>>  This is certainly true for AES, mostly because many small chips are
>>  including AES accelerators in hardware.  It's not quite true for public
>>  key solutions; there are still very small devices where even ECC takes
>>  too long (and yes, there are cases where 200-400ms is still too long).
>
>>  > It pays to look again at David Wagner's slides from 2005, on sensor
>>  > nets and crypto:
>>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>>  >
>
> Unattended sensors with wifi present an unsolved crypto problem.  They
> can last 10 years on an AA battery without crypto, probably well less
> than a year if they have to do any kind of encryption.  These things
> will be everywhere, providing the data that will underly all kinds of
> decision-making.

Assuming there are *some* integrity requirements for the data, and that
they are deploying 32-bit ARM with AES support (stipulating that ~every
CPU will have AES support in a few years, as ~every CPU sold does
today), we're talking about *either* an ECDHE negotiation every few
months or a pre-shared key, good for ten years.

AES-GCM with hardware support compares favorably to SHA-2 without
hardware support, so if they've been able to last 10 years before, they
should do just fine in the future.  The old devices won't last forever,
and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
for ten years after 1.3 is out.

-Brian

> Although much of the solution may lie in hardware innovation, the
> world really does need minimal crypto algorithms.
>
> Hilarie
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  From: Derek Atkins 
>  Date: Wed, 31 Aug 2016 10:17:25 -0400

>  "Steven M. Bellovin"  writes:

>  > Yes.  To a large extent, the "IoT devices are too puny for real
>  > crypto" is a hangover from several years ago. It was once true; for
>  > the most part, it isn't today, but people haven't flushed their cache
>  > from the old received wisdom.

>  This is certainly true for AES, mostly because many small chips are
>  including AES accelerators in hardware.  It's not quite true for public
>  key solutions; there are still very small devices where even ECC takes
>  too long (and yes, there are cases where 200-400ms is still too long).

>  > It pays to look again at David Wagner's slides from 2005, on sensor
>  > nets and crypto:
>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  >

Unattended sensors with wifi present an unsolved crypto problem.  They
can last 10 years on an AA battery without crypto, probably well less
than a year if they have to do any kind of encryption.  These things
will be everywhere, providing the data that will underly all kinds of
decision-making.

Although much of the solution may lie in hardware innovation, the
world really does need minimal crypto algorithms.

Hilarie



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Derek Atkins]

"Steven M. Bellovin"  writes:

> Yes.  To a large extent, the "IoT devices are too puny for real
> crypto" is a hangover from several years ago. It was once true; for
> the most part, it isn't today, but people haven't flushed their cache
> from the old received wisdom.

This is certainly true for AES, mostly because many small chips are
including AES accelerators in hardware.  It's not quite true for public
key solutions; there are still very small devices where even ECC takes
too long (and yes, there are cases where 200-400ms is still too long).

> It pays to look again at David Wagner's slides from 2005, on sensor
> nets and crypto:
> https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

David McGrew (mcgrew)  writes:

>That’s great, facts leaven a debate.

Yeah, but they also make it really boring, sigh.  *Opinions*, now those are
fun...

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[David McGrew (mcgrew)]

Hi Peter,



On 8/30/16, 5:41 AM, "Peter Gutmann"  wrote:

>David McGrew (mcgrew)  writes:
>
>>See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC
>>workshop last year:
>>http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf
>
>So looking at slide 6 from that, the first four systems he lists are desktop
>PCs (in all but form factor), it's only the last two that are down at the
>resource levels of IoT.  I'm not sure why he picked the Arduinos there because
>I wouldn't really consider them terribly representative of IoT devices, was it
>to get something that people are familiar with?  Even if you're wanting to
>restrict yourself to well-known complete systems I think at least an ESP8266
>(80Mhz SoC with 96K RAM, 64K flash, no multiply or divide by default) should
>get a mention.
>
>Slide 9 is even further removed from IoT practicality, that stuff may be fine
>on the PC-equivalents but won't work on real IoT gear.
>
>I'm currently working with some embedded systems guys to come up with a list
>of requirements for IoT crypto (as with the TLS-LTS stuff, various IP/legal
>issues means many contributors don't want to say anything in public), I'll
>post it to the list when we've finished arguing :-).
>
>Peter.

That’s great, facts leaven a debate.

thanks

David 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

Jon Callas  writes:

>Current cryptographic standards work for IoT

That's only if you use the circular argument that IoT is defined to be
whatever can run DTLS (or whatever you take as "current cryptographic
standards", the slides mention DTLS).  An yeah, I can then define my IoT to be
"whatever can't run DTLS" :-).  Stand by for a requirements list coming from a
bunch of IoT/embedded people...

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

David McGrew (mcgrew)  writes:

>See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC
>workshop last year:
>http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf

So looking at slide 6 from that, the first four systems he lists are desktop
PCs (in all but form factor), it's only the last two that are down at the
resource levels of IoT.  I'm not sure why he picked the Arduinos there because
I wouldn't really consider them terribly representative of IoT devices, was it
to get something that people are familiar with?  Even if you're wanting to
restrict yourself to well-known complete systems I think at least an ESP8266
(80Mhz SoC with 96K RAM, 64K flash, no multiply or divide by default) should
get a mention.

Slide 9 is even further removed from IoT practicality, that stuff may be fine
on the PC-equivalents but won't work on real IoT gear.

I'm currently working with some embedded systems guys to come up with a list
of requirements for IoT crypto (as with the TLS-LTS stuff, various IP/legal
issues means many contributors don't want to say anything in public), I'll
post it to the list when we've finished arguing :-).

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Steven M. Bellovin]

On 29 Aug 2016, at 17:46, Jon Callas wrote:



On Aug 29, 2016, at 5:44 AM, David McGrew (mcgrew)  
wrote:


Hi Peter,

You make a bunch of good points.   But it is also worth noting that 
some people feel that current crypto standards, including IETF 
standards, are suitable for IoT.   See for instance slides 8 and 9 of 
Daniel Shumow's talk at NIST’s LWC workshop last year: 
http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf 
  Also, CoAP isn’t on his list, but it could be, and it uses DTLS.  
 So while I agree with you that overuse of a 64-bit block cipher is 
far from the biggest security concern for IoT, the IETF should expect 
its protocols to be used in some IoT scenarios.


The malleability of the term IoT is causing trouble here.   Slide 6 
of Daniel’s talk is quite revealing.  To my thinking, by definition 
IoT devices are connected to the Internet in some way.


Definitely. But to quote Shumow's talk on Slide 10 (which has the 
title "IoT Does Not Need Its Own Crypto Standards"):


• Current cryptographic standards work for IoT
• Current standards are not a limit on IoT performance.
• Perspective: Common IoT platforms are approximately as
  powerful as PCs from 15 years ago when AES was standardized.

And on Slide 11:

• Adding new standards can be problematic:
• New standards, especially with lower key sizes could be
  used in scenarios where they aren’t intended.

Example: Standardizing ECC over 160bit prime for an RFID
  card and it ends up being used for https; block cipher
  with 80bit key space ends up being used to encrypt hard
  drives.

His conclusion (slide 13) says that we don't need Lightweight Crypto 
in software, but admits there are some hardware places (like RFID) for 
it.


And that gets to Peter's basic, good points. While Peter is being 
brash, his larger point is the same point as Shumow's, that we should 
just be using our existing toolbox and that even *that* has too many 
choices. The AllJoyn suite, which is the most stripped down, is 
brilliantly simple: RSA, ECDSA/ECDHE P256, and AES-CCM. You can 
quibble with it, but it's to the point. (My quibbles would be to toss 
RSA and Curve 41417 instead because it has an ARM NEON implementation 
that's as fast as P-160. But those are quibbles.)


Folding back up to the subject here -- AES is faster than DES. That is 
one of the reasons it was selected as AES. (So are Twofish and 
Serpent.) We need to toss all 64-bit block ciphers. They were okay way 
back in the 1900s. It is no longer then. AES is cheap and getting 
cheaper. We don't need to patch up any of those old ciphers with 
meshing or what. We just need to use what's in our toolbox. 3DES needs 
to go solely because it's a patch on DES that needs to be patched for 
its small block size. I know it's boring to just use AES, but it meets 
all the goals.


Yes.  To a large extent, the "IoT devices are too puny for real crypto" 
is a hangover from several years ago. It was once true; for the most 
part, it isn't today, but people haven't flushed their cache from the 
old received wisdom.


It pays to look again at David Wagner's slides from 2005, on sensor nets 
and crypto: https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf



--Steve Bellovin, https://www.cs.columbia.edu/~smb


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Ilari Liusvaara]

On Mon, Aug 29, 2016 at 12:44:42PM +, David McGrew (mcgrew) wrote:
> 
> The malleability of the term IoT is causing trouble here.   Slide 6
> of Daniel’s talk is quite revealing.  To my thinking, by definition
> IoT devices are connected to the Internet in some way.

Yes, the variability of capabilities of IoT devices is extreme. From
devices that just barely can run some cipher gated to PSK, to ones
that can easily run TLS without any hacks to save resources.

There is no way to make TLS realistically work for the first kind,
since just the flexibility of TLS would impose unreasonable burden,
even if profiled down.

If one limits oneself to the low end, I would think that anything
that can realistically handle any profile of TLS can probably handle
a real symmetric cipher (>=128 blocks, >=128 bit keys).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[John Mattsson]

Hi David and Peter,

I think Daniels presentation is a good summary and I tend to agree with
the “No lightweight cryptography in software”. But how relevant is
lightweight cryptography in IoT hardware? I been hearing some hardware
people stating that the number of gates is more and more irrelevant and
that the additional cost of 1000 GE is negligible with current
manufacturing techniques (i.e. 1000 GE is small compared to the are needed
to cut out the circuit and connecting it). We already know that the energy
cost of symmetric  crypto is negligible compared to wireless communication
(this might however change with passive radio).

Would be interesting to hear more input on the relevance of AES- and
SHA-replacements in IoT hardware. Depending on the outcome the CFRG way
forward should be either:

 - Recommendation how to use block ciphers with 64 bit block size
 - Recommendation not to use block ciphers with 64 bit block size

John


On 29/08/16 14:44, "Cfrg on behalf of David McGrew (mcgrew)"
 wrote:

>Hi Peter,
>
>You make a bunch of good points.   But it is also worth noting that some
>people feel that current crypto standards, including IETF standards, are
>suitable for IoT.   See for instance slides 8 and 9 of Daniel Shumow's
>talk at NIST’s LWC workshop last year:
>http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shu
>mow.pdf   Also, CoAP isn’t on his list, but it could be, and it uses
>DTLS.   So while I agree with you that overuse of a 64-bit block cipher
>is far from the biggest security concern for IoT, the IETF should expect
>its protocols to be used in some IoT scenarios.
>
>The malleability of the term IoT is causing trouble here.   Slide 6 of
>Daniel’s talk is quite revealing.  To my thinking, by definition IoT
>devices are connected to the Internet in some way.
>
>David
>
>
>
>On 8/28/16, 8:01 AM, "Peter Gutmann"  wrote:
>
>>David McGrew (mcgrew)  writes:
>>
>>>I don’t think you understood my point. IoT is about small devices
>>>connecting
>>>to the Internet, and IETF standards should expect designed-for-IoT
>>>crypto to
>>>be increasingly in scope.  It is important to not forget about these
>>>devices,
>>>amidst the current attention being paid to misuses of 64-bit block
>>>ciphers,
>>>which was the ultimate cause of this mail thread.
>>
>>But the IETF has a long history of creating standards that completely
>>ignore
>>IoT.  I can't think of a single general-purpose IETF security standard
>>(TLS,
>>SSH, IPsec, etc) that has any hope of working with IoT devices (say a
>>40Mhz
>>ARM-core ASIC with 32kB RAM and 64kB flash).  This is why the ITU/IEC
>>and a
>>million lesser-known standards bodies are all busy inventing their own
>>exquisitely homebrew crypto protocols, most of which make WEP look like a
>>model of good design.
>>
>>(I've always wanted to sit down and design a generic "encrypted pipe
>>from A to
>>B using minimal resources" spec, and I'm sure many other people have had
>>the
>>same thought at one time or another).
>>
>>So it seems like you've got:
>>
>>- The "TLS = the web" crowd (browser vendors and the like) who will
>>implement
>>  whatever's trendy at the moment and assume everyone has a quad-core
>>2GHz CPU
>>  with gigabytes of RAM and access to weekly live updates and hotfixes.
>>
>>- Embedded/SCADA folks who need to deal with 10-15 year product cycles
>>(see my
>>  TLS-LTS draft for more on this) and are kind of stuck.
>>
>>- IoT people, who can't use any standard protocol and will get the least
>>  unqualified person on staff to invent something that seems OK to them.
>>
>>I'm not sure that a draft on theoretical weaknesses in 64-bit block
>>ciphers is
>>going to affect any of those...
>>
>>Peter.
>___
>Cfrg mailing list
>c...@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[David McGrew (mcgrew)]

Hi Peter,

You make a bunch of good points.   But it is also worth noting that some people 
feel that current crypto standards, including IETF standards, are suitable for 
IoT.   See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC 
workshop last year: 
http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf
   Also, CoAP isn’t on his list, but it could be, and it uses DTLS.   So while 
I agree with you that overuse of a 64-bit block cipher is far from the biggest 
security concern for IoT, the IETF should expect its protocols to be used in 
some IoT scenarios.  

The malleability of the term IoT is causing trouble here.   Slide 6 of Daniel’s 
talk is quite revealing.  To my thinking, by definition IoT devices are 
connected to the Internet in some way.

David



On 8/28/16, 8:01 AM, "Peter Gutmann"  wrote:

>David McGrew (mcgrew)  writes:
>
>>I don’t think you understood my point. IoT is about small devices connecting
>>to the Internet, and IETF standards should expect designed-for-IoT crypto to
>>be increasingly in scope.  It is important to not forget about these devices,
>>amidst the current attention being paid to misuses of 64-bit block ciphers,
>>which was the ultimate cause of this mail thread.
>
>But the IETF has a long history of creating standards that completely ignore
>IoT.  I can't think of a single general-purpose IETF security standard (TLS,
>SSH, IPsec, etc) that has any hope of working with IoT devices (say a 40Mhz
>ARM-core ASIC with 32kB RAM and 64kB flash).  This is why the ITU/IEC and a
>million lesser-known standards bodies are all busy inventing their own
>exquisitely homebrew crypto protocols, most of which make WEP look like a
>model of good design.
>
>(I've always wanted to sit down and design a generic "encrypted pipe from A to
>B using minimal resources" spec, and I'm sure many other people have had the
>same thought at one time or another).
>
>So it seems like you've got:
>
>- The "TLS = the web" crowd (browser vendors and the like) who will implement
>  whatever's trendy at the moment and assume everyone has a quad-core 2GHz CPU
>  with gigabytes of RAM and access to weekly live updates and hotfixes.
>
>- Embedded/SCADA folks who need to deal with 10-15 year product cycles (see my
>  TLS-LTS draft for more on this) and are kind of stuck.
>
>- IoT people, who can't use any standard protocol and will get the least
>  unqualified person on staff to invent something that seems OK to them.
>
>I'm not sure that a draft on theoretical weaknesses in 64-bit block ciphers is
>going to affect any of those...
>
>Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hubert Kario]

On Sunday, 28 August 2016 13:55:47 CEST Peter Gutmann wrote:
> Stephen Farrell  writes:
> >IIRC the IoT marketing term doesn't have a very long history so I don't
> >really know what substance lies behind that remark.
> 
> I just used "IoT" because someone else had used it, since it's about as
> well- defined as "Web 2.0" I agree that it's not terribly useful to define
> a feature set.  What I meant was low-power embedded, smart meters and the
> like, IoT in the sense of "little internet-enabled things".

while others define it as "anything that is not a general purpose computer, 
tablet or phone", in effect including also SCADA, TVs, ATMs, traffic lights, 
etc.

and for those you need proper encryption
 
> >>(I've always wanted to sit down and design a generic "encrypted pipe from
> >>A
> >>to B using minimal resources" spec, and I'm sure many other people have
> >>had
> >>the same thought at one time or another).
> >
> >Then why don't you do that?
> 
> It's a bit like designing a new { OS | programming language | network
> protocol
> | ... }, everybody who works in the relevant field would like to have a go
> | at
> 
> something like this, and probably have a lot of fun fiddling with it, but
> I'm not sure how much appeal it would have to anyone apart from the person
> playing with it.  So the answer is "for the same reason I haven't had a go
> at designing a new OS, programming language, network protocol, etc".

we have enough problems weeding out implementation mistakes in TLS, we don't 
need yet another protocol and two dozen implementations that come with it

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

Stephen Farrell  writes:

>IIRC the IoT marketing term doesn't have a very long history so I don't
>really know what substance lies behind that remark.

I just used "IoT" because someone else had used it, since it's about as well-
defined as "Web 2.0" I agree that it's not terribly useful to define a feature
set.  What I meant was low-power embedded, smart meters and the like, IoT in
the sense of "little internet-enabled things".

>>(I've always wanted to sit down and design a generic "encrypted pipe from A
>>to B using minimal resources" spec, and I'm sure many other people have had
>>the same thought at one time or another).
>
>Then why don't you do that?

It's a bit like designing a new { OS | programming language | network protocol
| ... }, everybody who works in the relevant field would like to have a go at
something like this, and probably have a lot of fun fiddling with it, but I'm
not sure how much appeal it would have to anyone apart from the person playing
with it.  So the answer is "for the same reason I haven't had a go at
designing a new OS, programming language, network protocol, etc".

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Stephen Farrell]

Peter,

On 28/08/16 13:01, Peter Gutmann wrote:
> David McGrew (mcgrew)  writes:
> 
>> I don’t think you understood my point. IoT is about small devices connecting
>> to the Internet, and IETF standards should expect designed-for-IoT crypto to
>> be increasingly in scope.  It is important to not forget about these devices,
>> amidst the current attention being paid to misuses of 64-bit block ciphers,
>> which was the ultimate cause of this mail thread.
> 
> But the IETF has a long history of creating standards that completely ignore
> IoT.  

IIRC the IoT marketing term doesn't have a very long history so I
don't really know what substance lies behind that remark.

> I can't think of a single general-purpose IETF security standard (TLS,
> SSH, IPsec, etc) that has any hope of working with IoT devices (say a 40Mhz
> ARM-core ASIC with 32kB RAM and 64kB flash).  This is why the ITU/IEC and a
> million lesser-known standards bodies are all busy inventing their own
> exquisitely homebrew crypto protocols, most of which make WEP look like a
> model of good design.
> 
> (I've always wanted to sit down and design a generic "encrypted pipe from A to
> B using minimal resources" spec, and I'm sure many other people have had the
> same thought at one time or another).

Then why don't you do that? If others found it useful, then I'm sure
they'd want to use it and there'd be support for it in the IETF. (And
to be clear, I don't think your lts draft for TLS matches the above.)

One wrinkle though is that it seems that there's a real demand for
"encrypted pipe from A to B and hundreds of others using minimal
resources" spec - I'm not sure that the two party version is really
the main missing spec here.

S.

> 
> So it seems like you've got:
> 
> - The "TLS = the web" crowd (browser vendors and the like) who will implement
>   whatever's trendy at the moment and assume everyone has a quad-core 2GHz CPU
>   with gigabytes of RAM and access to weekly live updates and hotfixes.
> 
> - Embedded/SCADA folks who need to deal with 10-15 year product cycles (see my
>   TLS-LTS draft for more on this) and are kind of stuck.
> 
> - IoT people, who can't use any standard protocol and will get the least
>   unqualified person on staff to invent something that seems OK to them.
> 
> I'm not sure that a draft on theoretical weaknesses in 64-bit block ciphers is
> going to affect any of those...
> 
> Peter.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

Karthikeyan Bhargavan  writes:

>If every message IoT device sends is a 16 bytes message consisting of one 8
>byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we
>only need roughly 64GB in order to get a meaningful collision (50% chance of
>recovering the secret). The 768GB value we gave was for recovering cookies
>from realistic web browser traffic that could be triggered from JavaScript.

Sure, and I picked the 768GB value because it looks especially unrealistic
:-).  However, for typical SCADA/IoT even a value of 100MB is probably
unrealistic in practice, for the combined reasons that the device just isn't
interesting to attack, it doesn't send enough data to collect lots of it
unless you're prepared to wait a really long time, and, most importantly,
there are a thousand easier ways to get in if you really want to.

Has anyone every seen a SCADA device that stood up to even the smallest amount
of analysis/pen-testing?  I've currently got a rather pricey security
monitoring box sitting here awaiting investigation, and I can pretty much
guarantee I'll find something like unencrypted C, calling home to random
addresses overseas, unauthenticated firmware updates, and who knows what else,
just from simple Pineapple or Ettercap check, let alone any kind of active
pen-testing.

So I think it's important to distinguish between a cool demo in the lab and
something an attacker would actually do.  Of all the talks and demos I've seen
of people compromising SCADA and IoT devices, precisely zero even looked at
the crypto, let alone tried to attack it [0].  So if it's something that no-
one bothers attacking because there's always an easier way, it doesn't matter
how strong or weak it is.

As Ian Grigg recently put it:

  The problem we have is not how to get stronger crypto in place, it's how to
  get more crypto in place.

Securing something like MQTT would be a good start...

Peter.

[0] Alongside simply ignoring the fact that crypto may or may not be present,
I'm also taking things like "fails to check cert issuers" and "allows
unauthenticated remote firmware updates" as "not looking at the crypto".
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann]

David McGrew (mcgrew)  writes:

>I don’t think you understood my point. IoT is about small devices connecting
>to the Internet, and IETF standards should expect designed-for-IoT crypto to
>be increasingly in scope.  It is important to not forget about these devices,
>amidst the current attention being paid to misuses of 64-bit block ciphers,
>which was the ultimate cause of this mail thread.

But the IETF has a long history of creating standards that completely ignore
IoT.  I can't think of a single general-purpose IETF security standard (TLS,
SSH, IPsec, etc) that has any hope of working with IoT devices (say a 40Mhz
ARM-core ASIC with 32kB RAM and 64kB flash).  This is why the ITU/IEC and a
million lesser-known standards bodies are all busy inventing their own
exquisitely homebrew crypto protocols, most of which make WEP look like a
model of good design.

(I've always wanted to sit down and design a generic "encrypted pipe from A to
B using minimal resources" spec, and I'm sure many other people have had the
same thought at one time or another).

So it seems like you've got:

- The "TLS = the web" crowd (browser vendors and the like) who will implement
  whatever's trendy at the moment and assume everyone has a quad-core 2GHz CPU
  with gigabytes of RAM and access to weekly live updates and hotfixes.

- Embedded/SCADA folks who need to deal with 10-15 year product cycles (see my
  TLS-LTS draft for more on this) and are kind of stuck.

- IoT people, who can't use any standard protocol and will get the least
  unqualified person on staff to invent something that seems OK to them.

I'm not sure that a draft on theoretical weaknesses in 64-bit block ciphers is
going to affect any of those...

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Karthikeyan Bhargavan]

> Looking at it from the other side, your typical IoT device will be sending,
> for example, a 12-byte message every 15 minutes, meaning it'll take, if my
> calculations are right, just under two million years to collect the 785GB of
> data required to perform the attack.

I agree that it would be wise to evaluate each deployment scenario to decide
which vulnerabilities have higher priority. But just a brief comment.

If every message IoT device sends is a 16 bytes message consisting of one 8 
byte secret and one 8 byte known plaintext,
then with a 64-bit cipher, we only need roughly 64GB in order to get a 
meaningful collision (50% chance of recovering the secret).
The 768GB value we gave was for recovering cookies from realistic web browser 
traffic that could be triggered from JavaScript.

It is true that in other TLS use cases (such as IoT) some attacks may no longer 
be relevant, but unless we are careful
some HTTPS attacks may even be worse in these scenarios.

Best regards,
Karthik


> 
> So you've got something where the devices aren't vulnerable to the problem
> (and nor, in any practical case, is anything else), for which the devs
> involved won't even know that any guidance on the situation exists, and for
> which, if anyone really wants to attack them, they can use any of the dozens
> of insecure-by-design holes that are present in the device to own the whole
> thing, at which point what you do with your crypto becomes meaningless.
> 
> So what you're proposing is essentially a non-solution to a non-problem...
> still, if you feel like writing the memo for it, don't let me stand in your
> way.
> 
> Peter.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[David McGrew (mcgrew)]

Hi Tony,

Thanks for bringing this up; an RFC deprecating and/or discouraging 3DES would 
be a good thing.  The only good reason to use it is backwards compatibility, 
and too many applications don’t heed the birthday bound.

There is another issue to be considered, though.   Most of the lightweight 
“designed for IoT” block ciphers have a 64 bit block size (and sometimes even 
smaller); see for instance Table 1.1 of https://eprint.iacr.org/2013/404.pdf
 So perhaps what the Internet needs here is sound guidance on how to use 64-bit 
block ciphers.   Best practices here include both mandatory rekeying well below 
the birthday bound and/or the use of secure beyond the birthday bound modes of 
operation such as Iwata’s CENC.

Best,

David

From: Cfrg > on behalf of 
Tony Arcieri >
Date: Wednesday, August 24, 2016 at 10:08 PM
To: "tls@ietf.org" >, 
"c...@irtf.org" >
Subject: [Cfrg] 3DES diediedie

This attack was published today[*]:

https://sweet32.info/

I bring it up because I think the threat model is similar to the threats that 
lead to RC4 "diediedie"

https://www.rfc-editor.org/info/rfc7465

Should there be a 3DES "diediedie"?

I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense for it 
to be banned from TLS 1.3.

[*] Lest anyone claim the contrary, I am not surprised by this attack, and have 
pushed to have 3DES removed from TLS prior to the publication of this attack, 
and can probably find a TLS implementer who can back me up on that.

--
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hubert Kario]

On Thursday, 25 August 2016 09:55:10 CEST Ira McDonald wrote:
> Hi,
> 
> This survey of TLS in 1 million web servers shows that 93% support 3DES -
> oof!
> 
> https://jve.linuxwall.info/blog/index.php?post/TLS_Survey
> 
> 3DES hasn't quite disappeared on the Internet.

but less than 0.5% will actually negotiate it, while still between 2% and 3% 
will negotiate RC4:
https://securitypitfalls.wordpress.com/2016/08/07/april-2016-scan-results/

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Ira McDonald]

Hi,

This survey of TLS in 1 million web servers shows that 93% support 3DES -
oof!

https://jve.linuxwall.info/blog/index.php?post/TLS_Survey

3DES hasn't quite disappeared on the Internet.

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: blueroofmu...@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 Thu, Aug 25, 2016 at 9:33 AM, Eric Rescorla  wrote:

>
>
> On Thu, Aug 25, 2016 at 6:21 AM, david wong 
> wrote:
>
>> I don't think a RFC deprecating them is a good idea:
>>
>> * TLS 1.3 is almost here and is already doing that
>> * what browser still use 64-bit ciphers? Who lets his "old" browser open
>> for 75 hours?
>>
>
> Actually, I believe that all the major browsers support 3DES.
>
> -Ekr
>
> * in other uses of TLS. It's not always obvious if there is a possible
>> beast style attacks. And their implementation might really well not be
>> vulnerable (due to limiting number of messages according to specs)
>>
>> David
>> ___
>> Cfrg mailing list
>> c...@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
> ___
> Cfrg mailing list
> c...@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Eric Rescorla]

On Thu, Aug 25, 2016 at 6:21 AM, david wong 
wrote:

> I don't think a RFC deprecating them is a good idea:
>
> * TLS 1.3 is almost here and is already doing that
> * what browser still use 64-bit ciphers? Who lets his "old" browser open
> for 75 hours?
>

Actually, I believe that all the major browsers support 3DES.

-Ekr

* in other uses of TLS. It's not always obvious if there is a possible
> beast style attacks. And their implementation might really well not be
> vulnerable (due to limiting number of messages according to specs)
>
> David
> ___
> Cfrg mailing list
> c...@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[david wong]

I don't think a RFC deprecating them is a good idea:

* TLS 1.3 is almost here and is already doing that
* what browser still use 64-bit ciphers? Who lets his "old" browser open for 75 
hours?
* in other uses of TLS. It's not always obvious if there is a possible beast 
style attacks. And their implementation might really well not be vulnerable 
(due to limiting number of messages according to specs)

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hubert Kario]

On Wednesday, 24 August 2016 22:59:23 CEST Viktor Dukhovni wrote:
> I am not opposed to a "diediedie" RFC, if that is likely to be helpful.
> For TLS, this ciphersuite is already comparatively rare, and perhaps its
> disappearance will not be sped up by a "diediedie" RFC?  Would an RFC
> help to prod vendors into action more than the already published findings?
> Would our collective energies be better focused on other, more pressing
> goals?

People that care for support of Windows XP or Windows 2003 will use 3DES 
either way. People that don't care about those OSes, are probably already 
doing everything to not negotiate it, if only to conserve TLS terminator 
resources.

When RC4 die-die-die was published, a lot of servers negotiated RC4 (because 
of BEAST), it's not the case with 3DES.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Viktor Dukhovni]

> On Aug 24, 2016, at 10:34 PM, Tony Arcieri  wrote:
> 
> I am particularly interested in 3DES's usage in TLS, given its previous MTI 
> status in TLS, and because it was until very recently included in the OpenSSL 
> "DEFAULT" ciphersuite list.

For the record, it is only removed from the "DEFAULT" ciphersuite list in
tomorrow's (US/Eastern, today already for folks in Europe) 1.1.0 release.

In the 1.0.x releases it will change from "HIGH" to "MEDIUM", but remains
in "DEFAULT".  Users who elect just "HIGH" ciphers will not use 3DES, but
those who go with "DEFAULT" or explicitly include "MEDIUM" will generally
continue to enable 3DES as a low preference ciphersuite.

https://www.openssl.org/blog/blog/2016/08/24/sweet32/

My personal take is quoted in:

http://arstechnica.com/security/2016/08/new-attack-can-pluck-secrets-from-1-of-https-traffic-affects-top-sites/

   "We're not making a fuss about the 3DES issue, and rating it 'LOW',"
   Dukhovni wrote. "The 3DES issue is of little practical consequence at
   this time. It is just a matter of good hygiene to start saying goodbye
   to 3DES."

I am not opposed to a "diediedie" RFC, if that is likely to be helpful.
For TLS, this ciphersuite is already comparatively rare, and perhaps its
disappearance will not be sped up by a "diediedie" RFC?  Would an RFC
help to prod vendors into action more than the already published findings?
Would our collective energies be better focused on other, more pressing
goals?

-- 
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Wed, Aug 24, 2016 at 7:41 PM, Stephen Farrell 
wrote:

> On 25/08/16 03:34, Tony Arcieri wrote:
> I guess there's sometimes value in those die-die-die RFCs. Given that
> we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective
> key sizes less than 128 bits, one could argue that the IETF has covered
> that to a reasonable extent, in terms of RFCs saying to not do that.


Yes, aside from the 64-bit block size the the 112-bit (or sometimes
108-bit) key sizes are also notable for 3DES

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

It appears 3DES is not supported in TLS 1.3.

I would still support a "diediedie" RFC banning its use in previous
versions of TLS, despite its previous MTI status.

On Wed, Aug 24, 2016 at 7:34 PM, Tony Arcieri  wrote:

> On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk  wrote:
>
>> Well, there is
>> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00
>> but it is not really what you are looking for, I think, given the
>> recipient list on the message.
>
>
> I am particularly interested in 3DES's usage in TLS, given its previous
> MTI status in TLS, and because it was until very recently included in the
> OpenSSL "DEFAULT" ciphersuite list.
>
> --
> Tony Arcieri
>



-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk  wrote:

> Well, there is
> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00
> but it is not really what you are looking for, I think, given the
> recipient list on the message.


I am particularly interested in 3DES's usage in TLS, given its previous MTI
status in TLS, and because it was until very recently included in the
OpenSSL "DEFAULT" ciphersuite list.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls