+1 on the idea, but I am not convinced that the proposed process is sufficient (and/or terms are not adequately clear).
It seems to me that the time "for everyone to upgrade" will be dependent upon market factors related to the technology being replaced as well as with the severeness of the problem and the nature of the environment. In particular, I would generally expect that there might be different timelines for: 1. The new version being supported by newly purchased implementations 2. The new version being supported by all high-end equipment (e.g., servers) within data centers (i.e., upgrading things that are easy to upgrade) 3. The new version being supported by all equipment within data centers 4. The new version being supported by all high-end equipment installed in the field or mobile devices 5. The new version being supported by all field or mobile devices (e.g., even IoT sensors that use the technology) 6. The old version no longer being enabled Perhaps part of this was the concept of 1X and 2X because it is unclear why we would allow the use of the old technology if everyone supports the new technology. In any case, I think X is likely to be a variable that has to be established by consensus for each version of each technology (e.g., protocol). However, it might be possible to define a single variable per version while having a standardized formula that customizes the timeline for each of the above, e.g., (based on the item numbers above) 1. 1X 2. 1.5X 3. 1.75X 4. 1.5X 5. 2X 6. 2X I would assume that all of this would be presented as guidance as I don't think we can dictate what people actually market. This is why I listed item 6 as "enabled" implying that the market could still sell the old technology, but the goal is to make sure it is not being used. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > On Mar 3, 2023, at 1:17 PM, Nimrod Aviram <nimrod.avi...@gmail.com> wrote: > > Hi Everyone, > > We’ve recently had a brief side discussion around the issue of letting > vendors (or operators) know when something is expected to be deprecated: > https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/ > <https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/> > Currently, there is no expected deprecation timeline for any specific > primitive or protocol version. As one example, it seems like we plan to > deprecate RSA key exchange in TLS 1.2 soon (as part of > draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not explicitly > communicate this to vendors, and it seems like vendors either have to follow > the mailing list and deduce the likelihood of an upcoming deprecation, or > face a deprecation RFC at some random point in time (from their point of > view). > > And whatever the specifics of RSA key exchange deprecation, this will likely > not be the last time we deprecate something :-) > > Specifically, we will have to decide when/if to deprecate version 1.2 of TLS > within, say, the next 20 years. > > One possible solution is to publish “expected deprecation timeline” documents: > Let’s fix some timeframe which “is enough for everyone to upgrade at least > once” (famous last words, I know). I think of this timeframe as 3 or 5 years, > but it could as well be 8 or 10 years, and this solution would still be > viable; let’s denote the number of years as X. So, an “expected deprecation > timeline” document could specify that within X years, implementations MUST > support TLS 1.3, and within 2X years, implementations MUST NOT support TLS > 1.2. (If X=8 years, then we specify that by 2031 implementations MUST support > TLS 1.3, and by 2039 implementations MUST NOT support TLS 1.2.) This would > clarify the WG’s expectations to vendors, and would save the WG valuable time > discussing whether enough implementations in the field support the new > protocol/primitive. > > Is there interest here in such a solution? > > Credit where it’s due: This is based on an idea I heard from Dan Bernstein - > thanks Dan. > > Best, > Nimrod > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
