Re: [TLS] How are we planning to deprecate TLS 1.2?

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 <ekr@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.aviram@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