Hi Eliot,
Thanks for raising your concern. I’ll note that I first started working on
this because a well deployed library already had plans to drop support for
versions 1.0 and 1.1 in their next release. Customers that wanted those
versions would have to use a prior library. This history may help.
Best regards,
Kathleen
Sent from my mobile device
> On Nov 28, 2020, at 10:26 AM, Stephen Farrell
> wrote:
>
>
> Hi Eliot,
>
>> On 28/11/2020 10:45, Eliot Lear wrote:
>> Hi there IESG
>> I support the intent of this document, and I think the approach to
>> update the various documents listed is the right one.
>
> Cool.
>
>> Because of the breadth of documents updated, I wonder if at least
>> some implementation guidance is warranted, in order to assist
>> developers and even perhaps administrators. Perhaps in some cases
>> these are compile-time or even run time options. I’d suggest
>> guidance for common libraries, such as Microsoft .NET, OpenSSL,
>> GNUTLS, and WolfSSL. Better to give that guidance to get people to
>> TLS 1.3 rather than 1.2, of course. Even informational references
>> would be fine, as assuredly some of this guidance exists.
>
> Text welcomed of course, but I think it's mostly a case of
> doing the s/w update for the library and then either waiting
> 'till the library developer defaults to TLSv1.2 or better, or
> else various config file or API options that don't differ
> that much from library to library. I can check it out before
> we're done (again, text welcome if someone else wants to do
> that), but not sure it'll be that useful in the end TBH.
> (I'll get back when I get to doing that.)
>
> Cheers,
> S.
>
>> Thanks,
>> Eliot
On 9 Nov 2020, at 23:26, The IESG wrote:
>>> The IESG has received a request from the Transport Layer Security
>>> WG (tls) to consider the following document: - 'Deprecating TLSv1.0
>>> and TLSv1.1' as Best
>>> Current Practice
>>> The IESG plans to make a decision in the next few weeks, and
>>> solicits final comments on this action. Please send substantive
>>> comments to the last-c...@ietf.org mailing lists by 2020-11-30.
>>> Exceptionally, comments may be sent to i...@ietf.org instead. In
>>> either case, please retain the beginning of the Subject line to
>>> allow automated sorting.
>>> Abstract
>>> This document, if approved, formally deprecates Transport Layer Security
>>> (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those
>>> documents (will be moved|have been moved) to Historic status. These
>>> versions lack support for current and recommended cryptographic algorithms
>>> and mechanisms, and various government and industry profiles of
>>> applications using TLS now mandate avoiding these old TLS versions.
>>> TLSv1.2 has been the recommended version for IETF protocols since 2008,
>>> providing sufficient time to transition away from older versions. Removing
>>> support for older versions from implementations reduces the attack surface,
>>> reduces opportunity for misconfiguration, and streamlines library and
>>> product maintenance.
>>> This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347),
>>> but not DTLS version 1.2, and there is no DTLS version 1.1.
>>> This document updates many RFCs that normatively refer to TLSv1.0
>>> or TLSv1.1 as described herein. This document also updates the
>>> best practices for TLS usage in RFC 7525 and hence is part of
>>> BCP195.
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>>>
>>>
>>>
>>>
> No IPR declarations have been submitted directly on this I-D.
>>> The document contains these normative downward references. See RFC
>>> 3967 for additional information: rfc5024: ODETTE File Transfer
>>> Protocol 2.0 (Informational - Independent Submission Editor
>>> stream) rfc5024: ODETTE File Transfer Protocol 2.0 (Informational -
>>> Independent Submission Editor stream) rfc5023: The Atom Publishing
>>> Protocol (Proposed Standard - IETF stream) rfc5019: The Lightweight
>>> Online Certificate Status Protocol (OCSP) Profile for High-Volume
>>> Environments (Proposed Standard - IETF stream) rfc5019: The
>>> Lightweight Online Certificate Status Protocol (OCSP) Profile for
>>> High-Volume Environments (Proposed Standard - IETF stream) rfc5018:
>>> Connection Establishment in the Binary Floor Control Protocol
>>> (BFCP) (Proposed Standard - IETF stream) rfc4992: XML Pipelining
>>> with Chunks for the Internet Registry Information Service (Proposed
>>> Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the
>>> Internet Registry Information Service (Proposed Standard - IETF
>>> stream) rfc4976: Relay Extensions for the Message Sessions Relay
>>> Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The
>>> Message Session Relay Protocol (MSRP) (Proposed Standard - IETF
>>> stream) rfc4975: The Message Session Relay Protocol (MSRP)
>>> (Proposed Standard - IETF stream) rf
