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

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]