draft-ietf-tls-oldversions-deprecate-06.txt   draft-ietf-tls-oldversions-deprecate-07.txt 
Internet Engineering Task Force K. Moriarty Internet Engineering Task Force K. Moriarty
Internet-Draft Dell EMC Internet-Draft Dell EMC
Updates: 8465 8422 8261 7568 7562 7525 S. Farrell Obsoletes: 7507 (if approved) S. Farrell
7507 7465 7030 6750 6749 6739 Trinity College Dublin Updates: 8465 8422 8261 7568 7562 7525 Trinity College Dublin
6614 6460 6084 6083 6367 6347 January 6, 2020 7465 7030 6750 6749 6739 6614 October 9, 2020
6176 6042 6012 5878 5734 5469 6460 6084 6083 6367 6347 6176
5456 5422 5415 5364 5281 5263 6042 6012 5878 5734 5469 5456
5238 5216 5158 5091 5054 5049 5422 5415 5364 5281 5263 5238
5024 5023 5019 5018 4992 4976 5216 5158 5091 5054 5049 5024
4975 4964 4851 4823 4791 4785 5023 5019 5018 4992 4976 4975
4744 4743 4732 4712 4681 4680 4964 4851 4823 4791 4785 4744
4642 4616 4582 4540 4531 4513 4743 4732 4712 4681 4680 4642
4497 4279 4261 4235 4217 4168 4616 4582 4540 4531 4513 4497
4162 4111 4097 3983 3943 3903 4279 4261 4235 4217 4168 4162
3887 3871 3856 3767 3749 3656 4111 4097 3983 3943 3903 3887
3568 3552 3501 3470 3436 3329 3871 3856 3767 3749 3656 3568
3261 (if approved) 3552 3501 3470 3436 3329 3261
(if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: July 9, 2020 Expires: April 12, 2021
Deprecating TLSv1.0 and TLSv1.1 Deprecating TLSv1.0 and TLSv1.1
draft-ietf-tls-oldversions-deprecate-06 draft-ietf-tls-oldversions-deprecate-07
Abstract Abstract
This document, if approved, formally deprecates Transport Layer This document, if approved, formally deprecates Transport Layer
Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) and moves Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
these documents to the historic state. These versions lack support Accordingly, those documents (will be moved|have been moved) to
for current and recommended cipher suites, and various government and Historic status. These versions lack support for current and
industry profiles of applications using TLS now mandate avoiding recommended cryptographic algorithms and mechanisms, and various
these old TLS versions. TLSv1.2 has been the recommended version for government and industry profiles of applications using TLS now
IETF protocols since 2008, providing sufficient time to transition mandate avoiding these old TLS versions. TLSv1.2 has been the
away from older versions. Products having to support older versions recommended version for IETF protocols since 2008, providing
increase the attack surface unnecessarily and increase opportunities sufficient time to transition away from older versions. Removing
for misconfigurations. Supporting these older versions also requires support for older versions from implementations reduces the attack
additional effort for library and product maintenance. surface, reduces opportunity for misconfiguration, and streamlines
library and product maintenance.
This document also deprecates Datagram TLS (DTLS) version 1.0 This document also deprecates Datagram TLS (DTLS) version 1.0
(RFC6347), but not DTLS version 1.2, and there is no DTLS version (RFC6347), but not DTLS version 1.2, and there is no DTLS version
1.1. 1.1.
This document updates many RFCs that normatively refer to TLSv1.0 or This document updates many RFCs that normatively refer to TLSv1.0 or
TLSv1.1 as described herein. This document also updates RFC 7525 and TLSv1.1 as described herein. This document also updates the best
hence is part of BCP195. practices for TLS usage in RFC 7525 and hence is part of BCP195.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2020. This Internet-Draft will expire on April 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. RFCs Updated . . . . . . . . . . . . . . . . . . . . . . 3 1.1. RFCs Updated . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 4 2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 4
3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 . . . . . . . 5 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 . . . . . . . 5
4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6 4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6
5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 6 5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 6
6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 7 6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1
[RFC4346] were superceded by TLSv1.2 [RFC5246] in 2008, which has now [RFC4346] were superceded by TLSv1.2 [RFC5246] in 2008, which has now
itself been superceded by TLSv1.3 [RFC8446]. It is therefore timely itself been superceded by TLSv1.3 [RFC8446]. Datagram Transport
to further deprecate these old versions. Layer Security (DTLS) version 1.0 [RFC4347] was superceded by
DTLSv1.2 [RFC6347] in 2012. It is therefore timely to further
deprecate these old versions.
Technical reasons for deprecating these versions include: Technical reasons for deprecating these versions include:
o They require implementation of older cipher suites that are no o They require implementation of older cipher suites that are no
longer desirable for cryptographic reasons, e.g. TLSv1.0 makes longer desirable for cryptographic reasons, e.g., TLSv1.0 makes
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement
o Lack of support for current recommended cipher suites, especially o Lack of support for current recommended cipher suites, especially
using AEAD ciphers which are not supported prior to TLSv1.2. AEAD ciphers which are not supported prior to TLSv1.2. Note:
Note: registry entries for no-longer-desirable ciphersuites remain registry entries for no-longer-desirable ciphersuites remain in
in the registries, but many TLS registries are being updated the registries, but many TLS registries are being updated through
through [RFC8447] which denotes such entries as "not recommended." [RFC8447] which indicates that such entries are not recommended by
o Integrity of the handshake depends on SHA-1 hash the IETF.
o Authentication of the peers depends on SHA-1 signatures o Integrity of the handshake depends on SHA-1 hash.
o Support for four protocol versions increases the likelihood of o Authentication of the peers depends on SHA-1 signatures.
misconfiguration o Support for four TLS protocol versions increases the likelihood of
misconfiguration.
o At least one widely-used library has plans to drop TLSv1.1 and o At least one widely-used library has plans to drop TLSv1.1 and
TLSv1.0 support in upcoming releases; products using such TLSv1.0 support in upcoming releases; products using such
libraries would need to use older versions of the libraries to libraries would need to use older versions of the libraries to
support TLSv1.0 and TLSv1.1, which is clearly undesirable support TLSv1.0 and TLSv1.1, which is clearly undesirable.
Deprecation of these versions is intended to assist developers as Deprecation of these versions is intended to assist developers as
additional justification to no longer support older TLS versions and additional justification to no longer support older (D)TLS versions
to migrate to a minimum of TLSv1.2. Deprecation also assists product and to migrate to a minimum of (D)TLSv1.2. Deprecation also assists
teams with phasing out support for the older versions to reduce the product teams with phasing out support for the older versions, to
attack surface and the scope of maintenance for protocols in their reduce the attack surface and the scope of maintenance for protocols
offerings. in their offerings.
1.1. RFCs Updated 1.1. RFCs Updated
This document updates the following RFCs that normatively reference This document updates the following RFCs that normatively reference
TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of
these older versions. Fallback to these versions are prohibited these older versions. Fallback to these versions are prohibited
through this update. through this update. Specific references to mandatory minimum
protocol versions of TLSv1.0 or TLSv1.1 are replaced by TLSv1.2, and
[RFC8465] [RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7507] references to minimum protocol version DTLSv1.0 are replaced by
[RFC7465] [RFC7030] [RFC6750] [RFC6749] [RFC6739] [RFC6460] [RFC6084] DTLSv1.2. Statements that "TLS 1.0 is the most widely deployed
[RFC6083] [RFC6367] [RFC6176] [RFC6042] [RFC6012] [RFC5878] [RFC5734] version and will provide the broadest interoperability" are removed
[RFC5469] [RFC5456] [RFC5422] [RFC5415] [RFC5364] [RFC5281] [RFC5263] without replacement.
[RFC5238] [RFC5216] [RFC5158] [RFC5091] [RFC5054] [RFC5049] [RFC5024]
[RFC5023] [RFC5019] [RFC5018] [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC8465] [RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7465]
[RFC4851] [RFC4823] [RFC4791] [RFC4785] [RFC4744] [RFC4743] [RFC4732] [RFC7030] [RFC6750] [RFC6749] [RFC6739] [RFC6460] [RFC6084] [RFC6083]
[RFC4712] [RFC4681] [RFC4680] [RFC4642] [RFC4616] [RFC4582] [RFC4540] [RFC6367] [RFC6176] [RFC6042] [RFC6012] [RFC5878] [RFC5734] [RFC5469]
[RFC4531] [RFC4513] [RFC4497] [RFC4279] [RFC4261] [RFC4235] [RFC4217] [RFC5456] [RFC5422] [RFC5415] [RFC5364] [RFC5281] [RFC5263] [RFC5238]
[RFC4168] [RFC4162] [RFC4111] [RFC4097] [RFC3983] [RFC3943] [RFC3903] [RFC5216] [RFC5158] [RFC5091] [RFC5054] [RFC5049] [RFC5024] [RFC5023]
[RFC3887] [RFC3871] [RFC3856] [RFC3767] [RFC3749] [RFC3656] [RFC3568] [RFC5019] [RFC5018] [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC4851]
[RFC3552] [RFC3501] [RFC3470] [RFC3436] [RFC3329] [RFC3261] [RFC4823] [RFC4791] [RFC4785] [RFC4744] [RFC4743] [RFC4732] [RFC4712]
[RFC4681] [RFC4680] [RFC4642] [RFC4616] [RFC4582] [RFC4540] [RFC4531]
[RFC4513] [RFC4497] [RFC4279] [RFC4261] [RFC4235] [RFC4217] [RFC4168]
[RFC4162] [RFC4111] [RFC4097] [RFC3983] [RFC3943] [RFC3903] [RFC3887]
[RFC3871] [RFC3856] [RFC3767] [RFC3749] [RFC3656] [RFC3568] [RFC3552]
[RFC3501] [RFC3470] [RFC3436] [RFC3329] [RFC3261]
In addition these RFCs normatively refer to TLSv1.0 or TLSv1.1 and In addition these RFCs normatively refer to TLSv1.0 or TLSv1.1 and
have been obsoleted: [RFC5101] [RFC5081] [RFC5077] [RFC4934] have already been obsoleted; they are still listed here and marked as
[RFC4572] [RFC4507] [RFC4492] [RFC4366] [RFC4347] [RFC4244] [RFC4132] updated by this document in order to reiterate that any usage of the
[RFC3920] [RFC3734] [RFC3588] [RFC3546] [RFC3489] [RFC3316] obsolete protocol should still use modern TLS: [RFC7507] [RFC5101]
[RFC5081] [RFC5077] [RFC4934] [RFC4572] [RFC4507] [RFC4492] [RFC4366]
[RFC4347] [RFC4244] [RFC4132] [RFC3920] [RFC3734] [RFC3588] [RFC3546]
[RFC3489] [RFC3316]
In the case of [RFC4642], that has already been updated by [RFC8143] Note that [RFC4642] has already been updated by [RFC8143] ,which
which makes an overlapping, but not quite the same, update as this makes an overlapping, but not quite identical, update as this
document. document.
[RFC6614] has a requirement for TLSv1.1 although only makes an [RFC6614] has a requirement for TLSv1.1 or later, although only makes
informative reference to [RFC4346]. an informative reference to [RFC4346]. This requirement is updated
to be for TLSv1.2 or later.
This document updates DTLS [RFC6347]. This document updates DTLS [RFC6347]. [RFC6347] had allowed for
negotiating the use of DTLSv1.0, which is now forbidden.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Support for Deprecation 2. Support for Deprecation
Specific details on attacks against TLSv1.0 and TLSv1.1 as well as Specific details on attacks against TLSv1.0 and TLSv1.1, as well as
their mitigations are provided in NIST SP800-52r2 [NIST800-52r2], RFC their mitigations, are provided in NIST SP800-52r2 [NIST800-52r2],
7457 [RFC7457] and other referenced RFCs. Although the attacks have RFC 7457 [RFC7457] and other RFCs referenced therein. Although
been mitigated, if support is dropped for future library releases for mitigations for the current known vulnerabilities have been
these versions, it is unlikely attacks found going forward will be developed, any future issues discovered in old protocol versions
mitigated in older library releases. might not be mitigated in older library versions when newer library
versions do not support those old protocols.
NIST for example have provided the following rationale, copied with NIST for example have provided the following rationale, copied with
permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History
of TLS" (with references changed for RFC formatting). of TLS" (with references changed for RFC formatting).
TLS 1.1, specified in [RFC4346], was developed to address TLS 1.1, specified in [RFC4346], was developed to address
weaknesses discovered in TLS 1.0, primarily in the areas of weaknesses discovered in TLS 1.0, primarily in the areas of
initialization vector selection and padding error processing. initialization vector selection and padding error processing.
Initialization vectors were made explicit to prevent a certain Initialization vectors were made explicit to prevent a certain
class of attacks on the Cipher Block Chaining (CBC) mode of class of attacks on the Cipher Block Chaining (CBC) mode of
skipping to change at page 5, line 39 skipping to change at page 6, line 6
TLS 1.3 has been reduced considerably. TLS 1.3 has been reduced considerably.
3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1
The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1
hash of the exchanged messages. This makes it possible to perform a hash of the exchanged messages. This makes it possible to perform a
downgrade attack on the handshake by an attacker able to perform 2^77 downgrade attack on the handshake by an attacker able to perform 2^77
operations, well below the acceptable modern security margin. operations, well below the acceptable modern security margin.
Similarly, the authentication of the handshake depends on signatures Similarly, the authentication of the handshake depends on signatures
made using SHA-1 hash or a not stronger concatenation of MD-5 and made using a SHA-1 hash or a not appreciably stronger concatenation
SHA-1 hashes, allowing the attacker to impersonate a server when it of MD-5 and SHA-1 hashes, allowing the attacker to impersonate a
is able to break the severely weakened SHA-1 hash. server when it is able to break the severely weakened SHA-1 hash.
Neither TLSv1.0 nor TLSv1.1 allow the peers to select a stronger hash Neither TLSv1.0 nor TLSv1.1 allow the peers to select a stronger hash
for signatures in the ServerKeyExchange or CertificateVerify for signatures in the ServerKeyExchange or CertificateVerify
messages, making the only upgrade path the use of a newer protocol messages, making the only upgrade path the use of a newer protocol
version. version.
See [Bhargavan2016] for additional detail. See [Bhargavan2016] for additional detail.
4. Do Not Use TLSv1.0 4. Do Not Use TLSv1.0
TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of
TLS MUST NOT be permitted. TLS MUST NOT be permitted.
Any other version of TLS is more secure than TLSv1.0. TLSv1.0 can be Any other version of TLS is more secure than TLSv1.0. While TLSv1.0
configured to prevent interception, though using the highest version can be configured to prevent some types of interception, using the
available is preferable. highest version available is preferred.
Pragmatically, clients MUST NOT send a ClientHello with Pragmatically, clients MUST NOT send a ClientHello with
ClientHello.client_version set to {03,01}. Similarly, servers MUST ClientHello.client_version set to {03,01}. Similarly, servers MUST
NOT send a ServerHello with ServerHello.server_version set to NOT send a ServerHello with ServerHello.server_version set to
{03,01}. Any party receiving a Hello message with the protocol {03,01}. Any party receiving a Hello message with the protocol
version set to {03,01} MUST respond with a "protocol_version" alert version set to {03,01} MUST respond with a "protocol_version" alert
message and close the connection. message and close the connection.
Historically, TLS specifications were not clear on what the record Historically, TLS specifications were not clear on what the record
layer version number (TLSPlaintext.version) could contain when layer version number (TLSPlaintext.version) could contain when
skipping to change at page 6, line 42 skipping to change at page 7, line 5
TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of
TLS MUST NOT be permitted. TLS MUST NOT be permitted.
Pragmatically, clients MUST NOT send a ClientHello with Pragmatically, clients MUST NOT send a ClientHello with
ClientHello.client_version set to {03,02}. Similarly, servers MUST ClientHello.client_version set to {03,02}. Similarly, servers MUST
NOT send a ServerHello with ServerHello.server_version set to NOT send a ServerHello with ServerHello.server_version set to
{03,02}. Any party receiving a Hello message with the protocol {03,02}. Any party receiving a Hello message with the protocol
version set to {03,02} MUST respond with a "protocol_version" alert version set to {03,02} MUST respond with a "protocol_version" alert
message and close the connection. message and close the connection.
Any newer version of TLS is more secure than TLSv1.1. TLSv1.1 can be Any newer version of TLS is more secure than TLSv1.1. While TLSv1.1
configured to prevent interception, though using the highest version can be configured to prevent some types of interception, using the
available is preferable. Support for TLSv1.1 is dwindling in highest version available is preferred. Support for TLSv1.1 is
libraries and will impact security going forward if mitigations for dwindling in libraries and will impact security going forward if
attacks cannot be easily addressed and supported in older libraries. mitigations for attacks cannot be easily addressed and supported in
older libraries.
Historically, TLS specifications were not clear on what the record Historically, TLS specifications were not clear on what the record
layer version number (TLSPlaintext.version) could contain when layer version number (TLSPlaintext.version) could contain when
sending ClientHello. Appendix E of [RFC5246] notes that sending ClientHello. Appendix E of [RFC5246] notes that
TLSPlaintext.version could be selected to maximize interoperability, TLSPlaintext.version could be selected to maximize interoperability,
though no definitive value is identified as ideal. That guidance is though no definitive value is identified as ideal. That guidance is
still applicable; therefore, TLS servers MUST accept any value still applicable; therefore, TLS servers MUST accept any value
{03,XX} (including {03,00}) as the record layer version number for {03,XX} (including {03,00}) as the record layer version number for
ClientHello, but they MUST NOT negotiate TLSv1.1. ClientHello, but they MUST NOT negotiate TLSv1.1.
6. Updates to RFC7525 6. Updates to RFC7525
RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)", is the Security (TLS) and Datagram Transport Layer Security (DTLS)", which
most recent best practice document for implementing TLS and was based is the most recent best practice document for implementing TLS and
on TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not was based on TLSv1.2. At the time of publication, TLSv1.0 and
yet been deprecated. As such, this document is called out TLSv1.1 had not yet been deprecated. As such, this document is
specifically to update text implementing the deprecation called out specifically to update text implementing the deprecation
recommendations of this document. recommendations of this document.
This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to
MUST NOT as follows: MUST NOT as follows:
o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].
Rationale: TLSv1.0 (published in 1999) does not support many Rationale: TLSv1.0 (published in 1999) does not support many
modern, strong cipher suites. In addition, TLSv1.0 lacks a per- modern, strong cipher suites. In addition, TLSv1.0 lacks a per-
record Initialization Vector (IV) for CBC-based cipher suites and record Initialization Vector (IV) for CBC-based cipher suites and
skipping to change at page 7, line 44 skipping to change at page 8, line 9
This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to
MUST NOT as follows: MUST NOT as follows:
o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347], o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347],
[RFC6347]. [RFC6347].
Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).
7. Security Considerations 7. Security Considerations
This document deprecates two older protocol versions for security This document deprecates two older TLS protocol versions and one
reasons already described. The attack surface is reduced when there older DTLS protocol version for security reasons already described.
are a smaller number of supported protocols and fallback options are The attack surface is reduced when there are a smaller number of
removed. supported protocols and fallback options are removed.
8. Acknowledgements 8. Acknowledgements
Thanks to those that provided usage data, reviewed and/or improved Thanks to those that provided usage data, reviewed and/or improved
this document, including: David Benjamin, David Black, Alan DeKok, this document, including: David Benjamin, David Black, Alan DeKok,
Viktor Dukhovni, Julien Elie, Gary Gapinski, Alessandro Ghedini, Viktor Dukhovni, Julien Elie, Gary Gapinski, Alessandro Ghedini,
Jeremy Harris, James Hodgkinson, Russ Housley, Hubert Kario, John Jeremy Harris, James Hodgkinson, Russ Housley, Hubert Kario, John
Mattsson, Eric Mill, Yoav Nir, Andrei Popov, Eric Rescorla, Yaron Mattsson, Eric Mill, Yoav Nir, Andrei Popov, Eric Rescorla, Yaron
Sheffer, Robert Sparks, Martin Thomson, Loganaden Velvindron, and Sheffer, Robert Sparks, Martin Thomson, Loganaden Velvindron, and
Jakub Wilk. Jakub Wilk.
skipping to change at page 16, line 50 skipping to change at page 17, line 10
[RFC8465] Atarius, R., Ed., "Using the Mobile Equipment Identity [RFC8465] Atarius, R., Ed., "Using the Mobile Equipment Identity
(MEID) URN as an Instance ID", RFC 8465, (MEID) URN as an Instance ID", RFC 8465,
DOI 10.17487/RFC8465, September 2018, DOI 10.17487/RFC8465, September 2018,
<https://www.rfc-editor.org/info/rfc8465>. <https://www.rfc-editor.org/info/rfc8465>.
10.2. Informative References 10.2. Informative References
[Bhargavan2016] [Bhargavan2016]
Bhargavan, K. and G. Leuren, "Transcript Collision Bhargavan, K. and G. Leuren, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH Attacks: Breaking Authentication in TLS, IKE, and SSH
https://www.mitls.org/downloads/ https://www.mitls.org/downloads/transcript-
transcript-collisions.pdf", 2016. collisions.pdf", 2016.
[NIST800-52r2] [NIST800-52r2]
National Institute of Standards and Technology, "NIST National Institute of Standards and Technology, "NIST
SP800-52r2 https://csrc.nist.gov/CSRC/media/Publications/ SP800-52r2 https://csrc.nist.gov/CSRC/media/Publications/
sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf", sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf",
2018. 2018.
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
Second and Third Generation Cellular Hosts", RFC 3316, Second and Third Generation Cellular Hosts", RFC 3316,
 End of changes. 26 change blocks. 
99 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/