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

[Benjamin Kaduk <[e-mail]>]

Hi all,

Thank you for the robust discussion on this last-call thread (just a bit past
100 messages so far), including the interesting discussion (though arguably a
tangent to the document at hand by the end) about how the IETF can better
provide operational guidance and support robust and sustainable device
ecosystems and lifecycles.  While extended implementation guidance seems out
of scope for this document, reference(s) to such guidance elsewhere may be
useful, if the appropriate material to reference is located.

Though there were some relatively minor issues reported (Tom Petch noted a
botched reference or two, the gen-art and ops-dir reviews found some nits, and
John Klensin advocated for greater clarity on the relationship between RFC
5469 and RFC 5246), the bulk of the discussion focused on the potential harm
that would be caused by an immediate and universal move to TLS 1.2 as the
minimum version of TLS used at runtime or the removal of support for older TLS
versions from major software implementations such as TLS libraries or
browsers.

We heard about many classes of deployed systems that are in practice not
upgradeable (including due to the risk of breakage introduced by the update
process), and the knock-on effects on the local ecosystems that contain such
devices, including both where there are old TLS clients and where there are
old TLS servers, and a desire to have more text to acknowledge these use cases
and potentially indicate workarounds for them.  Many of these facts were
known to and considered by the WG at the decision to go forward with this
document around the time of IETF 102 (the benefits to the ecosystem were
deemed to outweight the breakage that would be incurred), but hearing it
again (and all in one place) is still useful.

We were also reminded that not only does the TLS ecosystem extend beyond the
Web, it also extends even to systems not connected to the Internet and
divorced from domain-name-based X.509 PKIs.  Such systems might (for example)
use RFC 1918 address space with iPAddress certificates, or pinned self-signed
certificates for TLS authentication.

A repeating theme was a desire by some participants to have some text as a
"hook" that indicates to sites that have already-fielded equipment
incompatible with the recommendations of this document that it is okay to
disregard its advice.  Other participants, however, expressed the sentiment
that a clear and unambiguous statement of best practices is preferred, with
many parties (presumably not the same ones that would benefit from the "hook")
having no difficulty in diverging from IETF guidelines.  Sentiments were
especially mixed as to the advisability of attempting to enumerate specific
exception cases where dropping old TLS versions would be harmful, as might
occur in such "hook" text.

There was also a proposal to keep TLS 1.0 and 1.1 enabled but treat it
identically to cleartext, though subsequent discussion concluded that
intentionally setting up a scenario where client and server disagree about
whether or not the traffic is secured seems ill-advised.

We heard about several classes of deployment for which an attempt to make this
change "overnight" would be a non-starter, with lead times measured in years
being necessary in order to achieve changes of this nature.  Fortunately, it
was clarified that publication of this document as a BCP would not require
such instant change; rather, this is the IETF describing what we believe to be
the best practices at the present time, with no immediate obligation to adhere
to such practices.  A transition period for moving from the present state of
any given deployment to the recommended state is called for, and this document
describes the motivation for the change so that each site can make an
assessment of their own risk and exposure, and thus, the pace at which to
transition.

In light of the expressed desire for long lead times in changes of this
nature, the question was raised as to when TLS 1.2 will be due for a similar
treatment, including whether it is advisable to choose and start advertising a
date for such a change now.  I note that TLS 1.3 features significant
improvements over TLS 1.2 on many axes, so I will encourage consideration
of this question in the TLS WG.


In conclusion, my assessment is that there is general IETF consensus to
publish this document in its current form, including the use of "MUST NOT"
language for the old TLS versions.  However, in the interest of clarity, we
should also provide some text to reiterate that this document reflects the
guidance from the IETF as to what are currently believed to be best practices
and why, but that whether or not (and how quickly) to adhere to the
IETF-provided best practices remains at the discretion of implementors and
operators.  Accordingly, I propose to add a new section just before the
Security Considerations section:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

7. Operational Considerations

This document is part of BCP 195, and as such reflects the understanding of
the IETF (at the time of its publication) as to the best practices for TLS
and DTLS usage.

Though TLS 1.1 has been obsolete since the publication of RFC 5246 in 2008,
and DTLS 1.0 has been obsolete since the publication of RFC 6347 in 2012,
there may remain some systems in operation that do not support (D)TLS 1.2 or
higher.  Adopting the practices recommended by this document for any systems
that need to communicate with the aforementioned class of systems will cause
failure to interoperate.  However, disregarding the recommendations of this
document in order to continue to interoperate with the aforementioned class of
systems incurs some amount of risk.  The nature of the risks incurred by
operating in contravention to the recommendations of this document are
discussed in Sections 2 and 3, and knowledge of those risks should be used
along with any potential mitigating factors and the risks inherent to
updating the systems in question when deciding how quickly to adopt the
recommendations specified in this document.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Thanks again for all the discussion here; it was quite productive.

-Ben