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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
