The document shepherd is Sean Turner.
The Area Director is Ben Kaduk.
This document formally deprecates Transport Layer Security (TLS)
versions 1.0 [RFC2246], TLS 1.1 [RFC4346], and DTLS 1.0 [RFC4347].
It moves these documents to the historic state. The draft is intended
for BCP because it updates 7525 and hence should be part of BCP195.
2. Review and Consensus
Let’s be clear, just about everybody wants to deprecate these older
versions of the protocol The question has always been when.
When this draft was first presented at IETF 102, there was
discussion about waiting to request publication until the
TLSv1.0 and TLSv1.1 use rates to drop to an “acceptable”
level. There were others that felt that there was no need to
wait and that the IETF should do what it thinks is right with
its protocols. The WG, obviously, settled on progressing this
draft. Note this draft was further discussed at IETF 103 and
104 to resolve comments received.
There was also some discomfort from enterprise users who
were concerned about the time and expense needed to
transition to newer versions. It should be noted that library
support typically continues for years beyond the publication
date of the RFC, e.g., OpenSSL released in Fall 2018 will
support TLSv1.0 and TLSv1.1 for roughly another 4 years.
The WGLC  did produce some fireworks. One participant
very strongly believes that “Disabling TLSv1.0 will only result
in lots of interop failures and pain, but no improvement in
security”. The assertion was that the use of (RSA,MD) and
(RSA,SHA-1) is allowed in TLS 1.2. This comment resulted in
draft-lvelvindron-tls-md5-sha1-deprecate, which deprecates
the use of MD5 and SHA1 in TLS1.2. The chairs determined
that this draft could proceed without the MD5/SHA1 deprecation
text as it is contained in another draft .
IETF LC also added two RFCs to the updates list and more
importantly a section was added to address operational
 Link to WGLC thread:
 Link to chair msg:
3. Intellectual Property
Each author has stated that their direct, personal knowledge
of any IPR related to this document has already been
disclosed, in conformance with BCPs 78 and 79.
4. Other Points
With so many updates in the header (they are there because
TLSv1.0 and TLSv1.1 were used by many protocols and the
WG wanted to do an exhaustive search on those protocols),
there are a couple of side effects:
1. BIKESHED ALERT: BIKESHED ALERT: There are a lot of
updates in the header, we really do not want these included
in the abstract.
2. DOWNREFS: There are a lot and I mean a lot of DOWNREF
warnings. None of these DOWNREFs are to be added to the
DOWNREF registry. If the RFC is already in the DOWNREF
registry fine, but do not add any there as a result of the IETF
LC for this document. The DOWNREFS are to RFCs: 3568,
3656, 3871, 3943, 4097, 4111, 4531, 4540, 4732, , 4743, 4744,
4823, 4851, 4964, 5024, 5054, 5091, 5158, 5281, 5422, 5469,
5878, 6042, 6367, 6739, 7562, 8465.
3. Obsolete informational references: There are lot of these
as well. They are all intentional.
There are no IANA considerations.