Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Christian de Larrinaga <[e-mail]>]

Nick Hilliard writes:

>
> What's relevant to the IETF is that it needs to make sound technical 
> recommendations about the usability and appropriateness of standards. 
> If organisations choose not to keep supporting some or all of their 
> product lines, this shouldn't impact the IETF's ability to do its job.
>
> Nick


However governments are busy writing up standards for managing the
secure  deployment of devices. The UK's DCMS has been working on this for a couple  of years

The local ISOC chapter has been engaging on this. On that count IETF
participants might like to keep engaged with those ISOC chapter
liaisons? Who I'm sure would be grateful for informed input as well. 

As a general observation the issue of vendors falling away from
supporting  devices is at odds with the promoted market model of
licensing IPR and maintaining restrictions over IPR after support falls
away.

Unless that IPR becomes public domain - or opened at least in regards
the scope of empowering the right to repair etc.

The practicalities of that is something IETF can think through as part
of its IPR policies?

Another observation is that manufacturer/vendors who force updates on
their  devices will tend to consider their own devices not others which
in context of "IoT" are very likely to also be interoperating from other vendors
or FOSS / hardware. That creates space for lots of stools for security to fall between. 

The issues around interoperability also means serving the responsibility
of user administrators across whatever pool of vendors or FOSS supply chains they choose to
deploy and commission support. Depending entirely on each vendor you use
has never been a good idea if you want a functional system.

So specifications to serve interoperability in terms of securing real world
installations of devices running from a selection of IETF defined
protocols is something IETF can think about too?

For discussion? I would expect that thinking to not assume "vendor" lock in but empower user
administrated support in concert with vendor support (if chosen (not
imposed)) as long as that is available and faciitate open alternatives particularly when that falls away.

This also seems a point where IETF specifications can offer
guidance. 



C
-- 
Christian de Larrinaga