Subject: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

From: Eliot Lear <[email-masked]>
Date: Sat, 5 Dec 2020 10:57:44 +0100

[moving to iotops and arch-discuss, as we are now leaving the topic of LC]

Ted,

I’m going to pick on you a bit here, but just to call out a larger point, because… we are almost nowhere on this problem.

> On 4 Dec 2020, at 23:47, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Why do people buy stuff that’s not upgradeable? Probably because the manufacturer doesn’t give them a choice, and there’s no way to force the choice. The recent discussions about legally requiring firmware-upgradeable IoT devices (e.g. in Singapore) is definitely a step in the right direction. For medical devices and medical infrastructure, this should have been required, but as far as I know still is not.

That premise is a bit too sweeping. Stuff doesn’t get upgraded for a myriad of reasons.  One is that stuff gets old.  Every manufacturer has this problem.  Cisco hardware is built to last, and it is not surprising to find equipment in the secondary market that is 15-20 years old.  If you look at a workhorse like a 7200 router that they (I wasn’t at Cisco yet) introduced in 1996, stopped selling in 2012, and only last year stopped issuing software patches for, you can still find equipment on the secondary market.  “Works like new”, $1,200 plus shipping[1].   In that span of time, just how many iPhones and Android systems have come and gone?*  What sort of eWaste problem has been created?  How long should DLink provide security updates for that frisbee that connects you to the world?  5 years? 10 years? 15 years?  Singapore didn’t answer that question, as I understand it.

And that’s in the IT market.  Now go look at the thermostat in your house.  How old is it?  In most cases, it dates back to when a house was built.  That’s the sign of a good product.  In some cases, the manufacturer may have gone out of business.    How long should an auto manufacturer support a car?  I will tell you that in general it is less than the length of time we support a router, and in some cases far less.  There are manufacturing presses that date back to the first use of electricity.  You think we have problems now?  Just wait a few years.

And then there is when and how to perform upgrades.  Apple along with a great many consumer providers has it easy when it comes to device upgrades: they can force the requirement that upgrades occur over the Internet, and that the device be rebooted.  Now try that with a transformer providing power to a hospital or a controller for an oil derrick in Alaska, where the duty cycle of a device can easily be 40 years, and the maintenance window is… oh wait.  There isn’t one.  Clearly these devices need to support in service upgrades, but even those have to be carefully thought out, tested, and planned.  And if something goes wrong, well...

My point isn’t that these upgrades shouldn’t occur.  But we do need to think differently about the whole life cycle of a system.  I’m far from the first to talk about this, nor is this insight particularly recent.  Dan Geer wrote as far back as 2012 about creating Internet kill switches[2,3].  Nor is this problem related only to security.  I’ve already mentioned the tension between security and eWaste. Cloud computing offers tremendous efficiencies, both economic and environmental, by shifting intelligence from dedicating computing to shared.  But think about what just happened this year: a number of manufacturers who use the cloud failed.  What happened to their products?  And of course Cloud computing by definition assumes Internet access, which the OT world is only beginning to allow.  After Amazon’s and Microsoft’s outages over the last several months, they may be a bit less interested.

Boiling this down, it seems to me IOT lifecycle, support models, and security models, including software ownership, open source, associated complexities, is a worthy topic to be picked up and discussed in iotops, given the life spans of some of these devices.

In answer to your direct question: yes we should be deprecating broken protocols faster than we have been.  The LC in question should have occurred at least five years ago, and it will more than justify the challenge it will give the RPC when they go to create the Updates: header ;-)

Eliot

* And don’t even get me started on Android and the vast technical deficit it and manufacturers created.  The absolutely naive and self-serving argument that only the h/w manufacturers are responsible for that mess demonstrates the limits of OSS.

[1] https://www.ebay.com/p/54829831 <https://www.ebay.com/p/54829831>
[2] https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf <https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf>
[3] https://queue.acm.org/detail.cfm?id=2479677 <https://queue.acm.org/detail.cfm?id=2479677>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 5 Dec 2020 11:40:48 -0500

I think we are mostly in violent agreement, Eliot, except that I think we (society, not the IETF necessarily) need an architecture for how to deal with the problems you’ve described. If we continue to sweep them under the carpet, we’re going to continue to see ransomware taking over hospitals and resulting in patient deaths or other adverse outcomes, loss of privacy in large enterprises, the continued ongoing data breaches that we see. Addressing the problems you’ve described won’t completely solve those problems, but it’s a necessary part of solving them.

I don’t think there’s a way to do this on a voluntary basis—it requires regulation, or there will always be an incentive not to do it, as you have so eloquently outlined.

> On Dec 5, 2020, at 4:57 AM, Eliot Lear <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2020 10:10:01 -0800

[ where are we going and why am i in this handbasket? ]

< rant >

when you have a plant which can turn out a jillion new thingies with a
day of set-up, the costs of the infrastructure to securely maintain and
upgrade them in the field for three, let alone 20, years is astronomical
in comparison.  now multiply that by a new and different thingie being
manufactured next month.  now multiply that by a few hundred
manufacturers.

perhaps the only way to understand in one's gut the scale of this
problem is to spend a few weeks in shenzhen.

to improve the math one would have to amortize the cost of maintenance
over many many flavors and makers of thingies.  so the acme thingie mfr,
and the hackme thingie mfr, and the ... need to have a common code base
and upgrade infrastructure.  this is seen as stifling innovation in a
highly innovative and competitive space.

the time from first pitch to vc term sheet and funding has gone down to
two weeks.  and the resulting landfill rivals the problem of plastics in
the oceans.

android is the only example i can think of with a multi-manufacturer
upgrade and maintenance infrastructure; and it is notoriously horrid.
researchers publish papers on how bad it is.  but credit to android for
trying.  long way to go.

alternatively, one could be in a regulated environment, e.g. military,
medical, etc., where multiplying the cost of the thingie by orders of
magnitude is seen as worth the social benefit.  but, even in these
environments, do not underestimate the attack surface due to sloppy ops.

we, for some value of we, are used building a reliable network from
unreliable components.  distributed protocols are the key.  that is a
different universe from a reliable and long-term maintainable thingie.
and maybe we don't want to use our favorite vendors' boat anchors as
examples.

randy, who still has a curta and a k&e log log duplex decitrig

---

From: Ted Lemon <[email-masked]>
Date: Sat, 5 Dec 2020 13:19:20 -0500

> two weeks.  and the resulting landfill rivals the problem of plastics in

The landfill issue is certainly heartbreaking. But most of those Shenzhen products you’re talking about are based on open source already. I’m not convinced that this particular problem is actually as intractable as you are suggesting.

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2020 10:27:38 -0800

> most of those Shenzhen products you’re talking about are based on open
> source already

and open source is notoriously secure, inspected, formally verified, and
well updated.  can you spell "m i r a i?"  how many kernel upgrades have
you had to do over the last month; and what percentage of ops did them?

randy

---

From: Ted Lemon <[email-masked]>
Date: Sat, 5 Dec 2020 13:32:23 -0500

> you had to do over the last month; and what percentage of ops did them?

I think you misunderstand. I’m not saying there’s not a problem. I’m saying that solving it maybe isn’t quite as hard as you’re suggesting. Most of these products, the manufacturer has already moved on after a year. They have no interest in maintaining the software, but they can dump it on github. They don’t because they don’t have to, not because they strongly care not to. If you bought a thousand units, it’s probably worth hiring someone to update it to TLS 1.3.

Getting Cisco to dump IOS on github is probably a bigger ask, but if the enterprise that’s buying the equipment is required for regulatory compliance to subscribe to updates, that creates a cash flow that can then be used to pay to do them. If the regulatory environment similarly requires that Cisco either do the updates, or allow someone to do them, then that problem is solved too.

Yes, this costs more than disposable technology, iff you don’t count the externalized costs.

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2020 10:46:01 -0800

> they can dump it on github

well chosen verb

now that github is owned by msoft, next year msoft ai will formally
verify and correct all the dren on github.  w00t!

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2020 10:48:25 -0800

> verify and correct all the dren on github.  w00t!

and, of course, once msoft ai fixes the code, it will magically and
securely distribute it to the 42 jillion deployed devices.

via luftschweinza

randy

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Dec 2020 10:54:08 -0800

I know you're just being sarcastic, but Microsoft, in cooperation with
INRIA and others has done a bunch of great work on code verification,
including:

- mitls - a verified TLS stack [https://www.mitls.org/]
- HACL* - verified implementations of a number of important cryptographic
algorithms [https://hacl-star.github.io/]

HACL* is actually seeing quite a bit of use. To quote from their site "Code
from HACL* has been incorporated into Firefox
<https://bugzilla.mozilla.org/show_bug.cgi?id=1387183>, the Windows kernel,
the Linux kernel, the Tezos blockchain
<https://www.reddit.com/r/tezos/comments/8hrsz2/tezos_switches_cryptographic_libraries_from/>,
the Microsoft MSQuic implementation of the QUIC protocol, and the Wireguard
VPN <https://lwn.net/Articles/770750/>."

-Ekr

On Sat, Dec 5, 2020 at 10:46 AM Randy Bush <[email-masked]> wrote:

> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2020 11:01:18 -0800

> I know you're just being sarcastic

moi?

> Microsoft, in cooperation with INRIA and others has done a bunch of
> great work on code verification

indeed.  impressive work.  and galois has a solid foot in a very
interesting part of the space too; as do a bunch of folk.

but i suspect that it will be at least until after the holidays that all
this will seriously improve the quality of the code 'dumped' on github.

randy

---

From: Christian Huitema <[email-masked]>
Date: Sat, 5 Dec 2020 11:43:38 -0800

> problem is to spend a few weeks in shenzhen.

That's indeed the big tension. People set up factories, hospitals and 
many other environments with a focus on their main mission, be it mass 
production of widget or the saving of lives. They don't want to stop 
doing what they are doing just because all the thermostats needs to be 
replaced. At the same time, we have ample evidence not replacing these 
obsolete little thermostats or other devices opens them to catastrophic 
failures, such as the casino that got hacked through an aquarium control 
device, the many hospitals that were hit by ransomware attacks, or the 
uranium enrichment plant that was crippled by a virus. So, what gives?

The Mirai worm attacked routers, which supposedly were acting as 
firewalls for home networks. That uranium enrichment plant was 
supposedly air-gapped. It is pretty clear that solutions based just on 
isolating networks with firewalls do not work in practice. But then, it 
is also clear that the current IAB recommendation of "regular software 
updates" does not work either. People don't do that because they fear 
the update itself will damage their network, or maybe because the device 
is so old that the manufacturer is not producing updates anymore, or for 
what other reason that I have yet to understand.

As Randy says, we are supposed to construct a reliable network from 
unreliable components. We are failing at that. What should we do? Should 
we recommend some form of preventive maintenance, in which devices are 
systematically replaced after some years, much like we currently 
systematically replace batteries or light bulbs before they fail? For 
devices that cannot be replaced, such as maybe MRI machines, should we 
suggest some kind of individual firewall that isolates them from the 
network? I don't know, and my ideas are probably wrong. But we need to 
have that discussion, and we need to have it with the people who 
actually manage plants, hospitals and other environments.

-- Christian Huitema

---

From: Amyas Phillips <[email-masked]>
Date: Sat, 5 Dec 2020 21:11:04 +0000

> On 5 Dec 2020, at 18:10, Randy Bush <[email-masked]> wrote:
> 
> and upgrade infrastructure.  

Exactly right, it’s hard to imagine any other economically viable way of maintaining devices which aren’t sold with a service contract. Even for devices which are sold with a service contract, this is still a cheaper and likely better way of delivering the security maintenance part of that service. 

There’s a few commercial products which do this. They essentially offer modules with an OS and application environment which they maintain for you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, Electric Imp, Ubuntu Core. They don’t maintain your application but that may well be a relatively small part of the attack surface, and possibly defended by features of the maintained environment. 

Microsoft Sphere in particular is interesting because the maintenance is completely hands off and the costs are folded into the initial BOM cost of the module, there’s no service fee.

Amyas

---

From: Eliot Lear <[email-masked]>
Date: Sun, 6 Dec 2020 13:32:34 +0100

> On 5 Dec 2020, at 22:11, Amyas Phillips <[email-masked]> wrote:
> 
> There’s a few commercial products which […] essentially offer modules with an OS and application environment which they maintain for you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, Electric Imp, Ubuntu Core. They don’t maintain your application but that may well be a relatively small part of the attack surface, and possibly defended by features of the maintained environment.
> 

It’s a start.  The question is long those contracts stay in place.  The issue is not 1, 2, or 3 years from purchase, but generally later.  The more recent the product was shipped the more motivation to fix it within the existing framework, as D-Link discovered.

In looking 10 years out, the aggregate exposure is lower due to the number of units, but that means that the maintenance costs, which are independent of outstanding units, need to be borne by a smaller based, or priced in at time of sale.  That’s not a small number for any but the largest companies.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Dec 2020 10:18:54 +0100

Great pportunity for a rant:

Its easy to understand how the mayority of participants in these discussions are
from either a commercial supplier side, or from a commercial user side. In either
case, a clearly time restricted use case scenario is easily be most important default.
This btw. also applies to where my pay check comes from (i think).

Nevertheless, i would highly recommend to no limit our design decisions to this
scenarios. 

Personally, i for once would be happy as an individual to see any standards be
blackmailed in the press and in public as an evil conspiracy for planned obsolescence
that does not consider the ability for devices to operate as long as their hardware can
without being constrained by 'security' software.

Obviously, there are also significant commercial applications undetermined long
life cycles are required. Just think of any deep space exploration NASA satellites
go dark because of their non-crypto agility. Or the non-desire to upgrade nuclear
missile control systems to new HW/SW because overall system security analysis
shows how new HW/SW more likely than not will be MORE susceptible to attacks than
simpler older SW/HW around for 50 years. Just two extreme examples.

I am not 10% sure about generic approaches to solve this problem, but one approach
could be the following:

- A device communications is designed to be able to operate solely within a
  "walled garden" environment. Not as the ONLY option, but as one option.

- Walled garden means that all communication channels of the device can be directed
  to go through other nodes of the "walled garden".

- "Walled garden" should IMHO also mean that the higher layer semantic of
  all communications is well enough defined/documented, so that another device
  in the walled-garden can be set up to convert/proxy the communications.

- Aka: If the crypto starts to become obsolete, then the obsolete crypto would
  be possible to constrain to the walled-carden (physical security) environment,
  and be proxied, and if the original remote communication parties do not exist
  anymore, but the data to be exchanged exists, then such a proxy could also
  proxy/convert the data into the 'legacy' format.

The ability to understand all the information communicated well enough to be able
to re-recreate the format is also necessary for any type of higher-layer security
filtering, so this type of communications design is not only good for longevity,
but also for security beyond transit confidentiality.

Cheers
    Toerless

On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote:
> Exactly right, it???s hard to imagine any other economically viable way of maintaining devices which aren???t sold with a service contract. Even for devices which are sold with a service contract, this is still a cheaper and likely better way of delivering the security maintenance part of that service. 
> 
> There???s a few commercial products which do this. They essentially offer modules with an OS and application environment which they maintain for you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, Electric Imp, Ubuntu Core. They don???t maintain your application but that may well be a relatively small part of the attack surface, and possibly defended by features of the maintained environment. 
> 
> Microsoft Sphere in particular is interesting because the maintenance is completely hands off and the costs are folded into the initial BOM cost of the module, there???s no service fee.
> 
> Amyas

> -- 
> Iotops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iotops

-- 
---
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 7 Dec 2020 09:43:07 -0500

It used to be that vendors announced end-of-life for products years after
introduction. For example, there was no way for a purchaser of Windows NT
to know, at purchase time, how long Microsoft was intending to support the
operating system. Now, better vendors seem to have started to make some
commitments, e.g., "this Android phone will receive new versions of the OS
for three releases and security updates until 2025". All the major Linux
distributions now have some kind of an LTS version, with long-term
stability and security/bug upgrades planned. There have been proposals (in
the UK?) of making vendors of IoT equipment state their support commitment,
so that a purchaser can choose "cheap" or "lasts a lifetime".
Unfortunately, industry advocacy is often for minimal regulation - there's
an opportunity here for ISOC and others to make a difference.

One reason for not upgrading: OS dependencies. Apple Big Sur (and Catalina)
broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep my
printer working. Dell, the distributor of the printers (made by Fuji-Xerox,
apparently) simply states that "due to circumstances beyond their control",
they won't be providing any Catalina/Big Sur printer drivers.

Given that most commercial systems are now assembled out of open-source
components, with customization or glue on top, you'd want some kind of
automated component checker. "17 of your components have not committed to
long-term support. Are you prepared to fix them yourselves?"

I don't know if this is feasible in all cases, but I suspect we often know
that certain technologies are getting long in the tooth. They are not quite
obsolete (historic) yet, but there's no active development or community and
they probably shouldn't be components that can't be replaced in the field.
No need (or resources) to do this for every RFC, but identifying critical
pieces of technology and providing a support roadmap would be helpful, I
think.

On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert <[email-masked]> wrote:

> > Exactly right, it???s hard to imagine any other economically viable way
> of maintaining devices which aren???t sold with a service contract. Even
> for devices which are sold with a service contract, this is still a cheaper
> and likely better way of delivering the security maintenance part of that
> service.
> >
> > There???s a few commercial products which do this. They essentially
> offer modules with an OS and application environment which they maintain
> for you, to a more or less hands-off degree: msoft Sphere, Balena,
> Particle, Electric Imp, Ubuntu Core. They don???t maintain your application
> but that may well be a relatively small part of the attack surface, and
> possibly defended by features of the maintained environment.
> >
> > Microsoft Sphere in particular is interesting because the maintenance is
> completely hands off and the costs are folded into the initial BOM cost of
> the module, there???s no service fee.
> >
> > Amyas
>
> > --
> > Iotops mailing list
> > [email-masked]

---

From: Sávyo Vinícius <[email-masked]>
Date: Mon, 7 Dec 2020 13:43:37 -0300

Another point we need to pay attention to is the situation of the SMEs
running in the local market of in-development-countries.
These companies are in a vulnerable position and can, after just launching
a device, close due to bankruptcy, shortening the device update life cycle.
People who just bought the device will not just discard the expensive
device, even knowing about the risks -- when the most probable is they
never know about them.

I really believe in the efficacy of an open source-based approach, but
there is a long way to develop a consistent framework (including community,
regulation, best practices, and other relevant stuff) to do it.
Still in this context, regulatory approaches need much attention because
they can be restrictive to those companies, and contribute to more
bankruptcies.

Another approach that can be taken is by creating a kind of contractual
best practices (maybe informational RFCs?) for advising different sectors
on what kind of terms they need to care about when building or buying
solutions. But this brings the challenge of how to make this information
reach the intended targets that are out of the IETF scope.

Em seg., 7 de dez. de 2020 às 11:43, Henning Schulzrinne <
[email-masked]> escreveu:

> One reason for not upgrading: OS dependencies. Apple Big Sur (and
> Catalina) broke a lot of printer drivers, so I had a choice: Upgrade my OS
> or keep my printer working. Dell, the distributor of the printers (made by
> Fuji-Xerox, apparently) simply states that "due to circumstances beyond
> their control", they won't be providing any Catalina/Big Sur printer
> drivers.
>
>> > Microsoft Sphere in particular is interesting because the maintenance
>> is completely hands off and the costs are folded into the initial BOM cost
>> of the module, there???s no service fee.
>> >
>> > Amyas
>>
>> > --
>> > Iotops mailing list
>> > [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Dec 2020 08:48:52 -0800

> regulation, best practices, and other relevant stuff) to do it.

https://xkcd.com/2347/

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Dec 2020 17:56:54 +0100

When i buy a glass or marmelade, the packaging indicates all the ingredients
and epecially also all aditives. So i can kinda be an educated consumer.

I i am always thinking that i would like similar labelling for equivalent,
especially about the (external) dependencies to continue operating the device.

Yes, there are all type of devices, and you mention one extreme, which are
general purpose devices (mobile phones). Even when i have an embedded device
with android, the dependencies to keep it running will typically be much more
constrained but difficult to understand for most users.

Maybe an organization like IETF could first start to document the problem of
such external dependencies. Taxonomy etc. pp. Starting with the most obvious
problem of certificate management. Then dependencies against external protocol
peers, possible cloud-services, crypto-agility...

E.g.: If you had to decide between two different options for one type of
device and you where worried about longevity: whats all the stuff you would
need to know about it, and which pieces would make a difference.

IMHO, this is all way too much in its infancy to think about regulation i think.
Once three is a better and broader agreement as to what the best practices
are for apsects in support of longevity... then one could think about
supportive measures to encourage vendors.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2020 17:24:47 -0500

> so that a purchaser can choose "cheap" or "lasts a lifetime".

yes, that's in the upcoming legislation.
This document hints at it:
     https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/773867/Code_of_Practice_for_Consumer_IoT_Security_October_2018.pdf

This was a call for views that ended in September:
  https://www.gov.uk/government/publications/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views

  Box 4 - Requirement 3 - Provide transparency on for how long, at a minimum,
  the product will receive security updates

  Exact wording and approach to be finalised

  The ‘defined support period’ for the relevant ‘product’ shall be published
  in an ‘accessible way’ that is ‘clear and transparent’.

  This clause aligns with provision 5.3-13 of European Telecommunications
  Standards Institute (ETSI) European Standard (EN) 303 645 v2.1.1.

    > they won't be providing any Catalina/Big Sur printer drivers.

My mom's computer is just "too old", yet it is perfectly functional.

    > long-term support. Are you prepared to fix them yourselves?"

Some kind of expert system perhaps.
Who'd pay to maintain this?  And would it, itself, go out of support?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2020 17:50:56 -0500

> they can be restrictive to those companies, and contribute to more

http://geer.tinho.net/geer.blackhat.6viii14.txt
and
https://www.blackhat.com/us-14/video/cybersecurity-as-realpolitik.html

What can the IETF do?
Mostly what we are already doing, which is to make it
cheaper and easier to build products where the clients and the servers don't
have to be vertically integrated.

... some text to tease you into going to read/listen-to the whole thing:

3. Source code liability -- CHOICE

Nat Howard said that "Security will always be exactly as bad as it
can possibly be while allowing everything to still function,"[NH]
but with each passing day, that "and still function" clause requires
a higher standard.  As Ken Thompson told us in his Turing Award
lecture, there is no technical escape;[KT] in strict mathematical
terms you neither trust a program nor a house unless you created
it 100% yourself, but in reality most of us will trust a house built
by a suitably skilled professional, usually we will trust it more
than one we had built ourselves, and this even if we have never met
the builder, or even if he is long since dead.

The reason for this trust is that shoddy building work has had that
crucial "or else ..." clause for more than 3700 years:

    If a builder builds a house for someone, and does not construct
    it properly, and the house which he built falls in and kills
    its owner, then the builder shall be put to death.
	-- Code of Hammurabi, approx 1750 B.C.

Today the relevant legal concept is "product liability" and the
fundamental formula is "If you make money selling something, then
you better do it well, or you will be held responsible for the
trouble it causes."  For better or poorer, the only two products
not covered by product liability today are religion and software,
and software should not escape for much longer.  Poul-Henning Kamp
and I have a strawman proposal for how software liability regulation
could be structured.

---

From: Sávyo Vinícius <[email-masked]>
Date: Tue, 8 Dec 2020 11:40:57 -0300

> https://www.blackhat.com/us-14/video/cybersecurity-as-realpolitik.html

I agree that we need to put as much effort as is possible to reinforce
security, but a
regulation becomes useless if it only allows the commercialization of
devices that
nobody can afford. Regulations need to create a tradeoff between protection
and
affordability and this turns harder in in-development-countries.

What can the IETF do?
> have to be vertically integrated.

... and we have a long way to go, but a starting point could be this issue
raised by RFC 8576 (section 5.5):

"Like all commercial devices, IoT devices have a given useful
lifetime. [...] A user should still be able to use and
perhaps even update the device.  This requires for some form of
authorization handover.

[...] CyanogenMod for Android devices and OpenWrt for home routers
are two such instances where users have been able to use and update
their devices even after the official EOL. Admittedly, it is not easy
for an average user to install and configure their devices on their
own.  With the deployment of millions of IoT devices, simpler mechanisms
are needed to allow users to add new trust anchors [RFC6024] and install
software and firmware from other sources once the device is EOL."

So how should we tackle this?
Develop a framework to simplify the third part development of
software/firmware updates after the EOL?
And how to integrate SUIT work on it?

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Dec 2020 13:52:53 -0800

https://www.wired.com/story/amnesia33-iot-vulnerabilitiesmay-never-get-fixed/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 9 Dec 2020 07:50:09 +0100

Hi Randy

> On 8 Dec 2020, at 22:52, Randy Bush <[email-masked]> wrote:
> 

Yes.  That article hits on nearly every security and incentive problem the IOT industry has.

Eliot