Re: [Iotops] [arch-d] 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

[Sávyo Vinícius <[e-mail]>]

Michael Richardson <[e-mail]> wrote:

> http://geer.tinho.net/geer.blackhat.6viii14.txt
> and
> 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?
> 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.
>

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