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

Reply via email to