just want to point of out that at least in the IETF that RFC 9325 [1] was recently published.
spt [1] https://datatracker.ietf.org/doc/rfc9325/ > On Mar 3, 2023, at 13:40, Eric Rescorla <e...@rtfm.com> wrote: > > Nimrod, > > Thanks for bringing this up. I don't think we really have had much of a > discussion. > > I *do* think we should be thinking about deprecating TLS 1.2 at some point, > not so much because > it is bad (though of course we believe TLS 1.3 is better) but because it's > better to just have > one thing that we work on and not have to reason about/work on TLS 1.2. And > of course, we really > don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum. > > I don't have strong feelings about the timeline. > > -Ekr > > > > > On Fri, Mar 3, 2023 at 10:18 AM 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/ > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
