Subject: Re: [Cfrg] [TLS] 3DES diediedie

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 6 Sep 2016 11:41:32 +0000

But who says that you'd want to run AES on PIC?‎ The whole point is that there are smaller cheaper ciphers usable on PIC.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Joachim Strömbergson
Sent: Tuesday, September 6, 2016 02:36
To: Hilarie Orman
Cc: [email-masked]; [email-masked]
Subject: Re: [Cfrg] [TLS] 3DES diediedie

Aloha!

Hilarie Orman wrote:
>> On 31 August 2016 at 20:48, Hilarie Orman
>> <[email-masked]> wrote:
> 
>>>> From: Brian Sniffen <[email-masked]>
> 
>> 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...
> 
> 
> Power.
> 
> Hilarie

Did you look at the ARM Cortex M0+ Gecko Zero I pointed to? I'd
recommend that you compare its power consumption to a PIC.

The PIC is manufactured using larger geometries that consumes more
power/gate/MHz. The Gecko Zero has more power modes allowing it to
enable/disable different functions very fast, and is able to scale its
own internal clock frequency very flexibly. The Gecko Zero (and other
M0+ devices) can also do more/cycle so that total power up time is
shortened, saving power.

Specifically (since we talked about it before), the AES core in the
Gecko Zero takes about 50 cycles to process one block (and the CPU core
can be powered down at the same time). Googling for cycles to perform
AES on PIC I found:

Encryption
PIC16F877 : 3834 cycles
PIC16F84 : 7157 cycles

https://edipermadi.wordpress.com/2008/02/09/an-aes-implementation-on-pic16f877/

So on the PIC you need to have the CPU core powered up and running about
80 times longer (in terms of cycles) than the Gecko needs to run its AES
core.

And even if you don't have an AES core, the ARM can do AES in fewer
cycles. This one shows 2270 cycles for AES-128

http://www.cryptovia.com/ARM_Thumb_AES.html

Selecting 8/16 bit MCUs like AVR, PIC, 8051 in 2016 for power reasons
without looking at modern 32-bit MCUs based on ARM or MIPS is a mistake
imho.

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

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Joachim Strömbergson Secworks AB [email-masked]
========================================================================

_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Joachim Strömbergson <[email-masked]>
Date: Tue, 06 Sep 2016 13:54:23 +0200

Aloha!

The point is that you _can_ run the highly standardized AES cipher and
meet cost, power consumption and use case (including response times,
performance) requirements on modern, low cost 32-bit MCUs even for
highly constrained IoT solutions.

Thus the need for smaller and cheaper ciphers that are less well known,
less proven, not generally available in peers, hosts, servers are not
needed.

Yes, you can find solutions where ultra light ciphers are needed, but
thanks to Moore's law those cases has rapidly diminished. More so than
people in general seem to understand.

The implementation of the cipher is rarely the components that make or
break the design. And in terms of development cost, deployment cost and
the effort to convince buyers to trust something that is not AES, they
all increase. Things you also need to account for at system design time.

Yours
JoachimS

Blumenthal, Uri - 0553 - MITLL wrote:
> But who says that you'd want to run AES on PIC?‎ The whole point is
> that there are smaller cheaper ciphers usable on PIC.
> 
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE
> network. Original Message From: Joachim Strömbergson Sent: Tuesday,
> September 6, 2016 02:36 To: Hilarie Orman Cc: [email-masked];
> [email-masked] Subject: Re: [Cfrg] [TLS] 3DES diediedie
> 
> Aloha!
> 
> Hilarie Orman wrote:
>>>  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...
> 
>> Power.
> 
>> Hilarie
> 
> enable/disable different functions very fast, and is able to scale
> its own internal clock frequency very flexibly. The Gecko Zero (and
> other M0+ devices) can also do more/cycle so that total power up time
> is shortened, saving power.
> 
> Gecko Zero takes about 50 cycles to process one block (and the CPU
> core can be powered down at the same time). Googling for cycles to
> perform AES on PIC I found:
> 
> Encryption PIC16F877 : 3834 cycles PIC16F84 : 7157 cycles
> 
>  So on the PIC you need to have the CPU core powered up and running
> about 80 times longer (in terms of cycles) than the Gecko needs to
> run its AES core.
> 
> Selecting 8/16 bit MCUs like AVR, PIC, 8051 in 2016 for power
> reasons without looking at modern 32-bit MCUs based on ARM or MIPS is
> a mistake imho.
> 
> 
> _______________________________________________ Cfrg mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/cfrg
> 

- --

---

From: Derek Atkins <[email-masked]>
Date: Tue, 06 Sep 2016 16:44:42 -0400

Hi,

> people in general seem to understand.

I'm afraid I have to disagree here.  What's it's done is pushed
yesterday's computation capabilities into smaller and smaller devices,
lower and lower on the food chain.  C.f. my previous email about a light
bulb.  Cost is definitely a concern, as well as power and performance.

So while yes, we can say "let's use an ARM Cortex Mx", that really
doesn't work in all cases.  So sure, we can wait yet another decade for
Moore's law to catch up with today's smart devices, but I suspect then
we'll have yet another class of even smaller devices.

> all increase. Things you also need to account for at system design time.

True..  but it can certainly be a factor.

> JoachimS

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Sep 2016 22:23:17 +0100

Hi Derek,

> bulb.  Cost is definitely a concern, as well as power and performance.

I think that's true but not the entire story.

Another part of the trade off is that any device that
connects to the Internet and runs s/w is potentially
vulnerable and usable to attack the network.

So we're not only talking about security/crypto to
protect someone's choice of what colour a bulb appears,
but rather we're very often talking about the protection
of a small computer on the network, and of the security
of the network as a whole.

That last I think argues strongly for support for
sufficiently good crypto everywhere. And I'm not sure
what sufficiently good options exist that are notably
lighter weight than AES. (And if one does support good
crypto then there seems less reason to use less good
crypto for some functions.)

Note that I'm arguing against weaker crypto or crypto
of unknown or possibly-problematic provenance here. So
I'm not arguing for HW-AES-everywhere. But it is also
true that AES-everywhere would avoid this significant
problem.

That said, I do realise that this is not a winning
argument as people will develop feature-rich devices
with crap security and there's no device-police to stop
them, but we (as in cfrg) should really also bear in
mind that any weaker crypto anywhere has significant
downsides as many devices really do need what we currently
consider strong crypto because they connect to the
Internet and may not get any updated s/w for quite some
time.

So... it's tricky - I think we know what's right but we
also know that that's not what "the market" is going
to produce;-)

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 6 Sep 2016 21:29:50 +0000

> So... it's tricky - I think we know what's right but we also know that that's not
> what "the market" is going to produce;-)

Consumer advances in safety and security == a new CASSANDRA working group.  Nobody will listen to us :)

---

From: Ira McDonald <[email-masked]>
Date: Tue, 6 Sep 2016 19:36:49 -0400

Hi,

I'm usually immediately corrected.

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

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

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

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

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

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

Cheers,
- Ira

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

---

From: Watson Ladd <[email-masked]>
Date: Tue, 6 Sep 2016 16:44:15 -0700

> but's it's a dangerous path IMHO.

This doesn't make the security issues with small blocksizes vanish. In
particular we've addressed the issue in TLS 1.3 with key rotation
mechanisms and lifetime limits.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Ira McDonald <[email-masked]>
Date: Tue, 6 Sep 2016 19:54:31 -0400

Hi Watson,

I wasn't arguing (and NIST isn't) for small blocksizes.

I was just trying to suggest that the common IETF/IRTF perception
that vertical industry demand for "lightweight cryptography" will just
go away is naive.  A lot of governments around the world and a lot
of ITU-T and ISO projects are predicated on the availability of one
or more "lightweight cryptography" algorithms.

It would be a good thing if cryptographers active in IETF/IRTF lists
would engage with these projects and use their expertise to point
out issues in specific algorithms.

Cheers,
- Ira

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Sep 2016 01:40:16 +0100

Hiya,

On 07/09/16 00:54, Ira McDonald wrote:
> go away is naive.  

It may also be unwise (though perhaps not naive) to assume
that developing a radically new technology is quicker than
just waiting until current-good stuff is sufficiently easy
and cheap to choose. Yes, I know the arguments against that,
but I also recall WAP - that is an existence proof that quite
large sections of industry can convince themselves of things
that just won't pan out, and never were going to - in that
case it took so long to develop the supposedly new thing that
the not-new thing (IP) was entirely usable before they got
done. Maybe it's an inherent part of such failures to be less
well remembered;-)

> A lot of governments around the world and a lot

Sure. And there's also a bunch of "5G requirements" that
call for breaches to the laws of physics in some network
near you in 2020. Just because a bunch of folks claim that
they want/need 1ms RTTs does not mean that can happen.

> out issues in specific algorithms.

Document a specific algorithm then, including its design
criteria and full documentation. Though I do hope we don't
end up spending loads of time thinking about algorithms
designed by organisations with a history of trying to promote
dodgy crypto. (*)

Personally, I think the approach of specifying crypto based
on device capability is broken. What ought (but won't) be
done is to map device capability to the sensitivity of the
application and to decide to use or not use that device for
that application. Even though the launch/don't-launch
decision for a missile is very simple, I would argue that
using the cheapest CPU for that is just wrong and bad design.
I'd also argue that engineers who choose to design things
that they know are insufficiently secure are doing the
equivalent of designing a bridge that will fall down in
normal use. I'd call both unethical, no matter that they
may produce bigger short-term profit. I also think that
the former just seems less unethical because we don't yet
have enough history of dealing with these things well, but
that will change. I would really not like to be the person
who in 20 years has to admit to having designed some of
the small-device crap that's now being deployed and that
expects to still be used in 20 years.

S.

(*) Yes, I mean simon and speck and nsa. I don't necessarily
include nist on that naughty-list. There is and totally should
be a durable and significant price to pay for dual-ec.

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 6 Sep 2016 19:16:12 -0700

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

There is definitely a middle ground here: there are 8-bit "secure MCUs"
with crypto accelerators.

Another factor to consider is how severely these devices have previously
failed from a security perspective: attackers pivoting from wireless tire
pressure sensors have been able to move laterally to ECUs, and at that
point are able to do any number of things that could cause a vehicle to
crash:

http://www.winlab.rutgers.edu/~Gruteser/papers/xu_tpms10.pdf

In every other space besides IoT hardware crypto accelerators are the norm.
They have certainly been the norm for the payments industry for decades,
but that's an industry that has much more experience with the risks,
whereas the "Internet of Cars" is relatively new.

I think the automotive industry needs to come to terms with with the fact
that it may need a "security budget", because there are definitely huge
risks that need to be addressed.

> but's it's a dangerous path IMHO.

Equally dangerous is deploying TLS insecurely. As an example of what I
consider necessary for security: are they capable of receiving fully
automated security updates? There have been a litany of TLS
vulnerabilities, especially recently, and unless these devices are capable
of these updates they will effectively be "insecure forever". In such a
case people may write off security concerns as "it's protected by TLS", but
they may be vulnerable to a Heartbleed-like attack, or perhaps they're
validating certificates incorrectly ala
https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf. These vulnerabilities
need to get fixed, or TLS is worthless.

I expect the answer to the "can these devices perform automated software
updates?" to be a resounding no. But if people really want to deploy TLS
successfully and securely for these use cases, that answer needs to change.

Is your 8-bit MCU with no crypto accelerator really up to the challenge?

-- 
Tony Arcieri

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 07 Sep 2016 09:50:30 +0200

Aloha!

Derek Atkins wrote:
> yesterday's computation capabilities into smaller and smaller
> devices, lower and lower on the food chain.  C.f. my previous email
> about a light bulb.  Cost is definitely a concern, as well as power
> and performance.

So far this year I've seen things like light bulbs, tyre pressure
sensors, tooth brushes, power meters, car door side panel controls,
melody gift cards that contain ARM based MCUs. It is not a decade away,
it is today.

> doesn't work in all cases.  So sure, we can wait yet another decade
> for Moore's law to catch up with today's smart devices, but I suspect
> then we'll have yet another class of even smaller devices.

And I claim that for a huge number of use cases, ARM based devices are
already there. In terms of price, in terms of power.

And, as I've tried to explain. Simpler (less gates) designs don't scale
down very good with Moore's law if the die size is I/O bound. You just
get more unused space (which is why MCUs gets more internal RAM memory
since that is what you easily can use the void for.)

What you gain is lower power consumption. Many MCUs still need to
support fairly high voltage I/Os (which makes the I/Os bigger on the die).

What I tried to show is that ARM based devices can do the same
processing as a PIC with the same power consumption. Some of them also
sports very good power modes that allows you to control the power
consumption. And specifically for AES you can get much better
performance and very much better power consumption with an AES core.
(There are some MSP430 and 8051 based 8-bit MCUs that also have AES
cores too.)

>> The implementation of the cipher is rarely the components that make
>> or break the design. And in terms of development cost, deployment
>> cost and the effort to convince buyers to trust something that is
>> not AES, they all increase. Things you also need to account for at
>> system design time.
> 

I don't think so. Look, I really love crypto stuff. And the Trivium
eSTREAM cipher in the embedded portfolio for example is a beautiful
design that shows what you can do with limited resources. Grain is
another lightweight cipher, and it has gotten some traction I think.

But unless you can get much better properties for your product in terms
of cost and performance (including battery life), you will have an
uphill battle in comparison to AES as your symmetric cipher.

At least where I live in Europe you have huge smart grids with up to
millions of power meter nodes in the network. All of them talks ZigBee
SmartEnergy or things close to it. That means AES in CCM mode. This is
what the customers are used to and expect. And it is what the developers
are used to, the support and service organizations are used too.

Coming to these orgs with a device that uses some other cipher requires
not only integration costs, but also the psychological cost of trying to
explain why 48 rounds of SIMON is better than 10 rounds of AES-128 that
has been tested, analyzed since 1997.

Researching lightweight ciphers is cool and good. But I don't expect to
see many symmetric primitives gain any major deployment. Where I think
we have a clear need for IoT is lightweight asymmetric primitives. Key
exchange, signatures etc. Too many devices use PSK simply because key
exchange is too costly, takes too long time.

If my work experience is anything to go by, if there are going to be any
new primitives being used, it will be from NaCl, that is Salsa och
Chacha, Poly1305 and Curve25519.

Where I specifically see a big need is for a good standardized firmware
update mechanism. Today everybody either rolls their own firmware
mechanism or get a (broken) one from their MCU vendor. I think there
were a new working group for this within the IETF. Can't remember and
can't find. But I think that it a very good idea.

- --

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Sep 2016 09:00:58 +0100

Hiya,

> can't find. But I think that it a very good idea.

We don't have an IETF WG for that, at least for now.
(If it made sense I'd be all for having one, but I'm
not sure we're at that point.)

You may be thinking of the IOTSU workshop [1] (that I
hosted:-). We've still to produce the report for that
and then see what actions may follow, but you can see
the raw minutes and submissions at [1]

Cheers,
S.

[1] https://down.dsg.cs.tcd.ie/iotsu/

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 7 Sep 2016 11:05:23 +0300

> exchange is too costly, takes too long time.

Unfortunately, the lightest weight asymmetric stuff currently known
that doesn't look to be broken to hell or at least look seriously
shaky is things like "Kummer" or "FourQ", which are like ~half of
the cost of Curve25519...

And I don't expect this to change, in fact, to get even worse when
considering PQ stuff.

Yes, RLWE is lighter CPU-wise than either of those two above, but
the extra communication costs from much larger keys will more than
offset that.

> can't find. But I think that it a very good idea.

I took a look at the IETF WGs, and didn't see anything that would look
relevant...

And proper update systems can be quite complicated. E.g. one framework
has 4 kinds of roles (not counting delegated subroles), and every
signature can be k-of-n.

-Ilari

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 07 Sep 2016 10:20:48 +0200

Aloha!

Stephen Farrell wrote:
> You may be thinking of the IOTSU workshop [1] (that I hosted:-).
> We've still to produce the report for that and then see what actions
> may follow, but you can see the raw minutes and submissions at [1]
> 
> Cheers, S.
> 

Ah, yes! I really wished I could have been there. Great initiative!

If there is any activities and I could provide any help, please let me know.

- --

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 07 Sep 2016 10:25:20 +0200

Aloha!

Ilari Liusvaara wrote:
>> Researching lightweight ciphers is cool and good. But I don't
>> expect to see many symmetric primitives gain any major deployment.
>> Where I think we have a clear need for IoT is lightweight
>> asymmetric primitives. Key exchange, signatures etc. Too many
>> devices use PSK simply because key exchange is too costly, takes
>> too long time.
> 
> shaky is things like "Kummer" or "FourQ", which are like ~half of the
> cost of Curve25519...
> 
> Yes, RLWE is lighter CPU-wise than either of those two above, but the
> extra communication costs from much larger keys will more than offset
> that.

I'm afraid that you are right. But as I said, this is one area where
good research result could have good traction in industry and be very
heopful.

>> Where I specifically see a big need is for a good standardized
>> firmware update mechanism. Today everybody either rolls their own
>> firmware mechanism or get a (broken) one from their MCU vendor. I
>> think there were a new working group for this within the IETF.
>> Can't remember and can't find. But I think that it a very good
>> idea.
> 
> I took a look at the IETF WGs, and didn't see anything that would
> look relevant...

It was Stephens workshop I was thinking of. I blame old age.

FW update is soo broken. Vendor solutions where the security is 3DES in
ECB mode only (no auth at all), solutions where you either can easily
get stuck in update mode, update and get stuck halfway through etc.

- --

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 7 Sep 2016 10:46:51 +0000

Stephen Farrell <[email-masked]> writes:

>We don't have an IETF WG for that, at least for now. (If it made sense I'd be
>all for having one, but I'm not sure we're at that point.)

I don't think it'll ever really make sense.  There are already a number of
standards for secure firmware update (RFC 4108 springs immediately to mind),
but in practice it's either not done at all or done in very system- and
vendor-specific ways.  That's not because vendors want to be gratuitously
proprietary, but because it's typically something that occurs at the BSP
level, which means its totally specific to a particular piece of hardware
and/or firmware and/or vendor.

Peter.

---

From: Derek Atkins <[email-masked]>
Date: Wed, 07 Sep 2016 10:32:23 -0400

Hi,

> of the network as a whole.

I agree completely, which is why I believe that "AES is the one true
cipher that everything must use" is, IMHO, a Bad Idea (TM).  As Peter
said in another email (thank you, Peter, for the GREAT writeup!!!),
while we do want better crypto, what's more important is MORE crypto.
We want more devices to use crypto, and if there are devices where even
AES can't be used (for whatever reason) we should find reasonable,
lower-"cost" alternatives.

> crypto for some functions.)

I know you're anti Simon/Speck, but there are a good dozen other
potential symmetric LWC candidates, based on ISO specification interest
and the NIST LWC workshop(s).

> true that AES-everywhere would avoid this significant

What's your definition of "weaker" crypto?

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

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

The Perfect is the enemy of the Good Enough.

> Internet and may not get any updated s/w for quite some

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

> also know that that's not what "the market" is going

I think this is the main issue -- different markets have different
needs.  And until you're living on an 8051 or MSP430 you really don't
understand how constrained you can be.

-derek

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 8 Sep 2016 12:32:57 +0100

Hiya,

> lower-"cost" alternatives.

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

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

> What's your definition of "weaker" crypto?

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

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

> attack than a 128-bit block size?

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

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

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

> The Perfect is the enemy of the Good Enough.

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

> (against a static "key").

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

> understand how constrained you can be.

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

Cheers,
S.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 08 Sep 2016 11:18:47 -0400

Hi,

> Hiya,
[snip]
> crypto no longer considered good enough, where possible.

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

[snip]
> much much rarer than many seem to think.

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

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

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

> what seems like the least sensitive interactions.

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

> the better algorithm for everything.

This is true.

> keys are already deployed and we have to live with it.)

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

> and IMO that's not something that device makers have yet

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

[snip]
> Figuring out sensible guidelines that are likely to be

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

> Internet. That's a big change though.

Yes, this is also true. Education is important.

-derek

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 8 Sep 2016 19:38:29 +0300

> than nothing (although if they can do 1DES they can do 3DES).

Because having the "lower bar", especially with "standard" protocols
lowers security FOR EVERYONE ELSE. Whitness the long litany of attacks
against TLS that exploit stuff that should have been nuked a long time
ago (but was kept for "compatiblity"; and similarly for other protocols).

(And the bad crypto is just a tip of the iceberg when it comes to the
insecurity of IoT stuff, and the reasons why I really don't want to
deal with any IoT devices if I can help it at all).

-Ilari

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Thu, 8 Sep 2016 15:09:14 -0600

> Whitness the long litany of attacks against TLS
> that exploit stuff that should have been nuked
> a long time ago (but was kept for "compatiblity";
> and similarly for other protocols).

Many of these attacks are made possible by poor design of the TLS protocol 
in the first place, which for some reason did not protect the integrity of 
algorithm negotiation, allowing for downgrade attacks, and requiring 
otherwise potentially useful algorithms to be eliminated because the 
algorithm negotiation is insecure.

For comparison, the design of SSH has not had this problem since around the 
year 2000.

denis

----- Original Message -----
From: Ilari Liusvaara
Sent: Thursday, September 8, 2016 10:38
To: Derek Atkins
Cc: Hilarie Orman ; [email-masked] ; JoachimStrömbergson
Subject: Re: [Cfrg] [TLS] 3DES diediedie

-Ilari