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]>]

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 <
[e-mail]> escreveu:

> 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
>>
> --
> Iotops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iotops
>