Deprecating TLS 1.0 and TLS 1.1
draft-ietf-tls-oldversions-deprecate-12

[Ballot comment]
I think this is the first time I’ve reviewed a document where the “References” section is longer than the rest of the document combined.

Just a couple of nits:

— Section 1.1 —

  Fallback to these versions are prohibited
  through this update.

Fallback “is” prohibited (not “are”).

— Section 6 —

  This documents updates [RFC7525] Section 3.1.1

“document”, singular.

[Ballot comment]
Thank you for the work put into this document.

Special thanks to the shepherd, Sean Turner, who did a great job to describe the WG consensus. Rob Wilton's point about minimum version is also important and should be addressed in the abstract (even if the text is clearer in section 1).

Please find below some nits.

I hope that this helps to improve the document,

Regards,

-éric

-- Abstract --
"This document, if approved, formally deprecates Transport Layer" => should ", if approved," be removed now from the abstract? The RFC Editor will probably do it though.

-- Section 1 --
"deprecate these old versions." should the "these old version" be followed by the enumeration ?

[Ballot comment]
Thank you for purging the old versions of TLS.

There is one sentence in the abstract that I found surprising (if it is right).

The abstract states: "TLSv1.2 has been the
  recommended version for IETF protocols since 2008, providing
  sufficient time to transition away from older versions."

Should this be "minimum recommended version"?  Otherwise, I don't understand why the recommended version of TLS is 1.2 rather than 1.3 (given that the TLS 1.2 RFC is marked as obsolete).

[Ballot comment]
Thank you for purging the old versions of TLS.

There was one sentence is the abstract that I found surprising (if it is right):

The abstract states: "TLSv1.2 has been the
  recommended version for IETF protocols since 2008, providing
  sufficient time to transition away from older versions."

Should this be "minimum recommended version"?  Otherwise, I don't understand why the recommended version of TLS is 1.2 rather than 1.3 (given that the TLS 1.2 RFC is marked as obsolete).

[Ballot comment]
The abstract states: "TLSv1.2 has been the
  recommended version for IETF protocols since 2008, providing
  sufficient time to transition away from older versions."

Should this be "minimum recommended version"?  Otherwise, I don't understand why the recommended version of TLS is 1.2 rather than 1.3 (given that the TLS 1.2 RFC is marked as obsolete).

[Ballot comment]
The replacement of (e.g.) "TLS 1.0" with "TLSv1.0" affected the quote from the NIST document,
which brings in slightly more divergence from the referenced material.

1. Summary

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  [0] 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 [1].

IETF LC also added two RFCs to the updates list and more
importantly a section was added to address operational
considerations.

[0] Link to WGLC thread:
https://mailarchive.ietf.org/arch/msg/tls/cupb-OgiSK1ulpRANAbihPHc7zI
[1] Link to chair msg:
https://mailarchive.ietf.org/arch/msg/tls/xyMXqKQUZeztD5WupvI0uBp4OLA

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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tls-oldversions-deprecate-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-11-30):

From: The IESG
To: IETF-Announce
CC: sean@sn3rd.com, tls@ietf.org, kaduk@mit.edu, tls-chairs@ietf.org, Kathleen Moriarty , draft-ietf-tls-oldversions-deprecate@ietf.org, Sean Turner
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice


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-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may
be sent to iesg@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)
    rfc4964: The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular (Informational - IETF stream)
    rfc4964: The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular (Informational - IETF stream)
    rfc4851: The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) (Informational - IETF stream)
    rfc4851: The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) (Informational - IETF stream)
    rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet (Informational - IETF stream)
    rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet (Informational - IETF stream)
    rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - IETF stream)
    rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - IETF stream)
    rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (Historic - IETF stream)
    rfc4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (Historic - IETF stream)
    rfc4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (Historic - IETF stream)
    rfc4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (Historic - IETF stream)
    rfc4732: Internet Denial-of-Service Considerations (Informational - IAB stream)
    rfc4732: Internet Denial-of-Service Considerations (Informational - IAB stream)
    rfc4712: Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) (Proposed Standard - IETF stream)
    rfc4712: Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) (Proposed Standard - IETF stream)
    rfc4681: TLS User Mapping Extension (Proposed Standard - IETF stream)
    rfc4680: TLS Handshake Message for Supplemental Data (Proposed Standard - IETF stream)
    rfc4680: TLS Handshake Message for Supplemental Data (Proposed Standard - IETF stream)
    rfc4642: Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) (Proposed Standard - IETF stream)
    rfc4642: Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) (Proposed Standard - IETF stream)
    rfc4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism (Proposed Standard - IETF stream)
    rfc4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism (Proposed Standard - IETF stream)
    rfc4582: The Binary Floor Control Protocol (BFCP) (Proposed Standard - IETF stream)
    rfc4582: The Binary Floor Control Protocol (BFCP) (Proposed Standard - IETF stream)
    rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental - Independent Submission Editor stream)
    rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental - Independent Submission Editor stream)
    rfc4531: Lightweight Directory Access Protocol (LDAP) Turn Operation (Experimental - IETF stream)
    rfc4513: Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms (Proposed Standard - IETF stream)
    rfc3436: Transport Layer Security over Stream Control Transmission Protocol (Proposed Standard - IETF stream)
    rfc3436: Transport Layer Security over Stream Control Transmission Protocol (Proposed Standard - IETF stream)
    rfc3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3261: SIP: Session Initiation Protocol (Proposed Standard - IETF stream)
    rfc3261: SIP: Session Initiation Protocol (Proposed Standard - IETF stream)
    rfc2246: The TLS Protocol Version 1.0 (Proposed Standard - IETF stream)
    rfc6749: The OAuth 2.0 Authorization Framework (Proposed Standard - IETF stream)
    rfc6739: Synchronizing Service Boundaries and  Elements Based on the Location-to-Service Translation (LoST) Protocol (Experimental - IETF stream)
    rfc6739: Synchronizing Service Boundaries and  Elements Based on the Location-to-Service Translation (LoST) Protocol (Experimental - IETF stream)
    rfc6367: Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational - IETF stream)
    rfc6367: Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational - IETF stream)
    rfc6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (Proposed Standard - IETF stream)
    rfc6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (Proposed Standard - IETF stream)
    rfc6042: Transport Layer Security (TLS) Authorization Using KeyNote (Informational - Independent Submission Editor stream)
    rfc5878: Transport Layer Security (TLS) Authorization Extensions (Experimental - IETF stream)
    rfc5469: DES and IDEA Cipher Suites for Transport Layer Security (TLS) (Informational - IETF stream)
    rfc5469: DES and IDEA Cipher Suites for Transport Layer Security (TLS) (Informational - IETF stream)
    rfc5422: Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational - IETF stream)
    rfc5422: Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational - IETF stream)
    rfc5364: Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists (Proposed Standard - IETF stream)
    rfc5364: Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists (Proposed Standard - IETF stream)
    rfc5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational - IETF stream)
    rfc5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational - IETF stream)
    rfc5263: Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information (Proposed Standard - IETF stream)
    rfc5263: Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information (Proposed Standard - IETF stream)
    rfc5238: Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) (Proposed Standard - IETF stream)
    rfc5216: The EAP-TLS Authentication Protocol (Proposed Standard - IETF stream)
    rfc5216: The EAP-TLS Authentication Protocol (Proposed Standard - IETF stream)
    rfc5158: 6to4 Reverse DNS Delegation Specification (Informational - IETF stream)
    rfc5091: Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems (Informational - IETF stream)
    rfc5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (Informational - IETF stream)
    rfc5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (Informational - IETF stream)
    rfc5049: Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (Proposed Standard - IETF stream)
    rfc3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (Proposed Standard - IETF stream)
    rfc4346: The Transport Layer Security (TLS) Protocol Version 1.1 (Proposed Standard - IETF stream)
    rfc2246: The TLS Protocol Version 1.0 (Proposed Standard - IETF stream)
    rfc4346: The Transport Layer Security (TLS) Protocol Version 1.1 (Proposed Standard - IETF stream)
    rfc4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4261: Common Open Policy Service (COPS) Over Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4235: An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc4235: An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc4217: Securing FTP with TLS (Proposed Standard - IETF stream)
    rfc4168: The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc4162: Addition of SEED Cipher Suites to Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4111: Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) (Informational - IETF stream)
    rfc4097: Middlebox Communications (MIDCOM) Protocol Evaluation (Informational - IETF stream)
    rfc4097: Middlebox Communications (MIDCOM) Protocol Evaluation (Informational - IETF stream)
    rfc3983: Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) (Proposed Standard - IETF stream)
    rfc3943: Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) (Informational - IETF stream)
    rfc3903: Session Initiation Protocol (SIP) Extension for Event State Publication (Proposed Standard - IETF stream)
    rfc6749: The OAuth 2.0 Authorization Framework (Proposed Standard - IETF stream)
    rfc3887: Message Tracking Query Protocol (Proposed Standard - IETF stream)
    rfc3871: Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure (Informational - IETF stream)
    rfc3871: Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure (Informational - IETF stream)
    rfc3856: A Presence Event Package for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3767: Securely Available Credentials Protocol (Proposed Standard - IETF stream)
    rfc3749: Transport Layer Security Protocol Compression Methods (Proposed Standard - IETF stream)
    rfc3749: Transport Layer Security Protocol Compression Methods (Proposed Standard - IETF stream)
    rfc3656: The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol (Experimental - Independent Submission Editor stream)
    rfc3568: Known Content Network (CN) Request-Routing Mechanisms (Informational - IETF stream)
    rfc6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (Proposed Standard - IETF stream)
    rfc6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (Proposed Standard - IETF stream)
    rfc7030: Enrollment over Secure Transport (Proposed Standard - IETF stream)
    rfc7030: Enrollment over Secure Transport (Proposed Standard - IETF stream)
    rfc7465: Prohibiting RC4 Cipher Suites (Proposed Standard - IETF stream)
    rfc7465: Prohibiting RC4 Cipher Suites (Proposed Standard - IETF stream)
    rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF stream)
    rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF stream)
    rfc7562: Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates (Informational - Independent Submission Editor stream)
    rfc7562: Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates (Informational - Independent Submission Editor stream)
    rfc7568: Deprecating Secure Sockets Layer Version 3.0 (Proposed Standard - IETF stream)
    rfc7568: Deprecating Secure Sockets Layer Version 3.0 (Proposed Standard - IETF stream)
    rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier (Proposed Standard - IETF stream)
    rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier (Proposed Standard - IETF stream)

1. Summary

The document shepherd is Sean Turner.
The Area Director is Ben Kaduk.

This document formally deprecates Transport Layer Security (TLS)
versions 1.0 [RFC2246] and 1.1 [RFC4346] and 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  [0] 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 [1].

[0] Link to WGLC thread:
https://mailarchive.ietf.org/arch/msg/tls/cupb-OgiSK1ulpRANAbihPHc7zI
[1] Link to chair msg:
https://mailarchive.ietf.org/arch/msg/tls/xyMXqKQUZeztD5WupvI0uBp4OLA

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.

1. Summary

The document shepherd is Sean Turner.
The Area Director is Ben Kaduk.

This document formally deprecates Transport Layer Security (TLS)
versions 1.0 [RFC2246] and 1.1 [RFC4346] and 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  [0] 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 [1].

[0] Link to WGLC thread:
https://mailarchive.ietf.org/arch/msg/tls/cupb-OgiSK1ulpRANAbihPHc7zI
[1] Link to chair msg:
https://mailarchive.ietf.org/arch/msg/tls/xyMXqKQUZeztD5WupvI0uBp4OLA

3. Intellectual Property

Colm

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.

1. Summary

The document shepherd is Sean Turner.
The Area Director is Ben Kaduk.

This document formally deprecates Transport Layer Security (TLS)
versions 1.0 [RFC2246] and 1.1 [RFC4346] and 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  [0] 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 [1].

[0] Link to WGLC thread:
https://mailarchive.ietf.org/arch/msg/tls/cupb-OgiSK1ulpRANAbihPHc7zI
[1] Link to chair msg:
https://mailarchive.ietf.org/arch/msg/tls/xyMXqKQUZeztD5WupvI0uBp4OLA

3. Intellectual Property

Colm

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.