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

[Toerless Eckert <[e-mail]>]

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


On Mon, Dec 07, 2020 at 09:43:07AM -0500, Henning Schulzrinne wrote:
> 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 <[e-mail]> wrote:
> 
> > 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:
> > >
> > > > On 5 Dec 2020, at 18:10, Randy Bush <[e-mail]> wrote:
> > > >
> > > > 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.
> > >
> > >
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/iotops
> >
> >
> > --
> > ---
> > [e-mail]
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >

-- 
---
[e-mail]