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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 4, 2020, at 5:29 PM, Ackermann, Michael <MAckermann@xxxxxxxxx> wrote:
Regards to the 12 years vs 1-2.    12 years is probably too long for just about anything, once it is determined to be a business need.   But that is the key first step.   Then it will likely be a minimum of 1-2 years to get the identified need in the budget and then into planning cycles and actual project plans.      For example, if you tell me to do a major conversion right now,  it is tool late at this point for me to even request that for the 2021 budget.    I could request this in 2021, for the 2022 budget.   Hence the typical minimum 1-2 years. 

But isn’t this the crux of the matter? How do we get to a place where when a new version of the protocol comes out, the planning starts? Should the IETF have deprecated TLS 1.1 in 2008? That would certainly have given you more lead time! I suspect there’s a happy medium.

Why do people buy stuff that’s not upgradeable? Probably because the manufacturer doesn’t give them a choice, and there’s no way to force the choice. The recent discussions about legally requiring firmware-upgradeable IoT devices (e.g. in Singapore) is definitely a step in the right direction. For medical devices and medical infrastructure, this should have been required, but as far as I know still is not.

I realize that this isn’t your specific problem, but it’s the one that really worries me.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux