draft-ietf-tls-oldversions-deprecate-09.txt   draft-ietf-tls-oldversions-deprecate-10.txt 
Internet Engineering Task Force K. Moriarty Internet Engineering Task Force K. Moriarty
Internet-Draft Dell EMC Internet-Draft Dell EMC
Obsoletes: 5469 7507 (if approved) S. Farrell Obsoletes: 5469 7507 (if approved) S. Farrell
Updates: 8422 8261 7568 7562 7525 7465 Trinity College Dublin Updates: 8422 8261 7568 7562 7525 7465 Trinity College Dublin
7030 6750 6749 6739 6460 6614 November 9, 2020 7030 6750 6749 6739 6460 6614 December 14, 2020
6367 6347 6176 6084 6083 6042 6367 6353 6347 6176 6084 6083
6012 5878 5734 5456 5422 5415 6042 6012 5953 5878 5734 5456
5364 5281 5263 5238 5216 5158 5422 5415 5364 5281 5263 5238
5091 5054 5049 5024 5023 5019 5216 5158 5091 5054 5049 5024
5018 4992 4976 4975 4964 4851 5023 5019 5018 4992 4976 4975
4823 4791 4785 4744 4743 4732 4964 4851 4823 4791 4785 4744
4712 4681 4680 4642 4616 4582 4743 4732 4712 4681 4680 4642
4540 4531 4513 4497 4279 4261 4616 4582 4540 4531 4513 4497
4235 4217 4168 4162 4111 4097 4279 4261 4235 4217 4168 4162
3983 3943 3903 3887 3871 3856 4111 4097 3983 3943 3903 3887
3767 3749 3656 3568 3552 3501 3871 3856 3767 3749 3656 3568
3470 3436 3329 3261 (if 3552 3501 3470 3436 3329 3261
approved) (if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: May 13, 2021 Expires: June 17, 2021
Deprecating TLSv1.0 and TLSv1.1 Deprecating TLSv1.0 and TLSv1.1
draft-ietf-tls-oldversions-deprecate-09 draft-ietf-tls-oldversions-deprecate-10
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). Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
Accordingly, those documents (will be moved|have been moved) to Accordingly, those documents (will be moved|have been moved) to
Historic status. These versions lack support for current and Historic status. These versions lack support for current and
recommended cryptographic algorithms and mechanisms, and various recommended cryptographic algorithms and mechanisms, and various
government and industry profiles of applications using TLS now government and industry profiles of applications using TLS now
mandate avoiding these old TLS versions. TLSv1.2 has been the mandate avoiding these old TLS versions. TLSv1.2 has been the
recommended version for IETF protocols since 2008, providing recommended version for IETF protocols since 2008, providing
sufficient time to transition away from older versions. Removing sufficient time to transition away from older versions. Removing
support for older versions from implementations reduces the attack support for older versions from implementations reduces the attack
surface, reduces opportunity for misconfiguration, and streamlines surface, reduces opportunity for misconfiguration, and streamlines
library and product maintenance. 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 (RFC4347), 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 the best TLSv1.1 as described herein. This document also updates the best
practices for TLS usage in RFC 7525 and 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.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 May 13, 2021. This Internet-Draft will expire on June 17, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 5 2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 5
3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 . . . . . . . 6 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 . . . . . . . 6
4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6 4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6
5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 7 5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 7
6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 8 6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Operational Considerations . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 superseded by TLSv1.2 [RFC5246] in 2008, which has now
itself been superceded by TLSv1.3 [RFC8446]. Datagram Transport itself been superseded by TLSv1.3 [RFC8446]. Datagram Transport
Layer Security (DTLS) version 1.0 [RFC4347] was superceded by Layer Security (DTLS) version 1.0 [RFC4347] was superseded by
DTLSv1.2 [RFC6347] in 2012. It is therefore timely to further DTLSv1.2 [RFC6347] in 2012. It is therefore timely to further
deprecate these old versions. Accordingly, those documents (will be deprecate these old versions. Accordingly, those documents (will be
moved|have been moved) to Historic status. moved|have been moved) to Historic status.
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
skipping to change at page 4, line 4 skipping to change at page 4, line 5
in their 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. Specific references to mandatory minimum through this update. Specific references to mandatory minimum
protocol versions of TLSv1.0 or TLSv1.1 are replaced by TLSv1.2, and protocol versions of TLSv1.0 or TLSv1.1 are replaced by TLSv1.2, and
references to minimum protocol version DTLSv1.0 are replaced by references to minimum protocol version DTLSv1.0 are replaced by
DTLSv1.2. Statements that "TLS 1.0 is the most widely deployed DTLSv1.2. Statements that "TLSv1.0 is the most widely deployed
version and will provide the broadest interoperability" are removed version and will provide the broadest interoperability" are removed
without replacement. without replacement.
[RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7465] [RFC7030] [RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7465] [RFC7030]
[RFC6750] [RFC6749] [RFC6739] [RFC6084] [RFC6083] [RFC6367] [RFC6176] [RFC6750] [RFC6749] [RFC6739] [RFC6084] [RFC6083] [RFC6367] [RFC6353]
[RFC6042] [RFC6012] [RFC5878] [RFC5734] [RFC5456] [RFC5422] [RFC5415] [RFC6176] [RFC6042] [RFC6012] [RFC5953] [RFC5878] [RFC5734] [RFC5456]
[RFC5364] [RFC5281] [RFC5263] [RFC5238] [RFC5216] [RFC5158] [RFC5091] [RFC5422] [RFC5415] [RFC5364] [RFC5281] [RFC5263] [RFC5238] [RFC5216]
[RFC5054] [RFC5049] [RFC5024] [RFC5023] [RFC5019] [RFC5018] [RFC4992] [RFC5158] [RFC5091] [RFC5054] [RFC5049] [RFC5024] [RFC5023] [RFC5019]
[RFC4976] [RFC4975] [RFC4964] [RFC4851] [RFC4823] [RFC4791] [RFC4785] [RFC5018] [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC4851] [RFC4823]
[RFC4732] [RFC4712] [RFC4681] [RFC4680] [RFC4642] [RFC4616] [RFC4582] [RFC4791] [RFC4785] [RFC4732] [RFC4712] [RFC4681] [RFC4680] [RFC4642]
[RFC4540] [RFC4531] [RFC4513] [RFC4497] [RFC4279] [RFC4261] [RFC4235] [RFC4616] [RFC4582] [RFC4540] [RFC4531] [RFC4513] [RFC4497] [RFC4279]
[RFC4217] [RFC4168] [RFC4162] [RFC4111] [RFC4097] [RFC3983] [RFC3943] [RFC4261] [RFC4235] [RFC4217] [RFC4168] [RFC4162] [RFC4111] [RFC4097]
[RFC3903] [RFC3887] [RFC3871] [RFC3856] [RFC3767] [RFC3749] [RFC3656] [RFC3983] [RFC3943] [RFC3903] [RFC3887] [RFC3871] [RFC3856] [RFC3767]
[RFC3568] [RFC3552] [RFC3501] [RFC3470] [RFC3436] [RFC3329] [RFC3261] [RFC3749] [RFC3656] [RFC3568] [RFC3552] [RFC3501] [RFC3470] [RFC3436]
[RFC3329] [RFC3261]
The status of [RFC7562], [RFC6042], [RFC5456], [RFC5024], [RFC4540], The status of [RFC7562], [RFC6042], [RFC5456], [RFC5024], [RFC4540],
and [RFC3656] will be updated with permission of the Independent and [RFC3656] will be updated with permission of the Independent
Stream Editor. Stream Editor.
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 already been obsoleted; they are still listed here and marked as have already been obsoleted; they are still listed here and marked as
updated by this document in order to reiterate that any usage of the updated by this document in order to reiterate that any usage of the
obsolete protocol should still use modern TLS: [RFC5101] [RFC5081] obsolete protocol should still use modern TLS: [RFC5101] [RFC5081]
[RFC5077] [RFC4934] [RFC4572] [RFC4507] [RFC4492] [RFC4366] [RFC4347] [RFC5077] [RFC4934] [RFC4572] [RFC4507] [RFC4492] [RFC4366] [RFC4347]
skipping to change at page 5, line 6 skipping to change at page 5, line 8
This document updates DTLS [RFC6347]. [RFC6347] had allowed for This document updates DTLS [RFC6347]. [RFC6347] had allowed for
negotiating the use of DTLSv1.0, which is now forbidden. negotiating the use of DTLSv1.0, which is now forbidden.
The DES and IDEA cipher suites specified in [RFC5469] were The DES and IDEA cipher suites specified in [RFC5469] were
specifically removed from TLSv1.2 by [RFC5246]; since the only specifically removed from TLSv1.2 by [RFC5246]; since the only
versions of TLS for which their usage is defined are now Historic, versions of TLS for which their usage is defined are now Historic,
RFC 5469 (will be|has been) moved to Historic as well. RFC 5469 (will be|has been) moved to Historic as well.
The version-fallback Signaling Cipher Suite Value specified in The version-fallback Signaling Cipher Suite Value specified in
[RFC7507] waas defined to detect when a given client and server [RFC7507] was defined to detect when a given client and server
negotiate a lower version of (D)TLS than their highest shared negotiate a lower version of (D)TLS than their highest shared
version. TLSv1.3 ([RFC8446]) incorporates a different mechanism that version. TLSv1.3 ([RFC8446]) incorporates a different mechanism that
achieves this purpose, via sentinel values in the ServerHello.Random achieves this purpose, via sentinel values in the ServerHello.Random
field. With (D)TLS versions prior to 1.2 fully deprecated, the only field. With (D)TLS versions prior to 1.2 fully deprecated, the only
way for (D)TLS implementations to negotiate a lower version than way for (D)TLS implementations to negotiate a lower version than
their highest shared version would be to negotiate (D)TLSv1.2 while their highest shared version would be to negotiate (D)TLSv1.2 while
supporting (D)TLSv1.3; supporting (D)TLSv1.3 implies support for the supporting (D)TLSv1.3; supporting (D)TLSv1.3 implies support for the
ServerHello.Random mechanism. Accordingly, the functionality from ServerHello.Random mechanism. Accordingly, the functionality from
[RFC7507] has been superseded, and this document marks it as [RFC7507] has been superseded, and this document marks it as
Obsolete. Obsolete.
skipping to change at page 5, line 36 skipping to change at page 5, line 38
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 [NIST800-52r2], RFC 7457 [RFC7457] their mitigations, are provided in [NIST800-52r2], RFC 7457 [RFC7457]
and other RFCs referenced therein. Although mitigations for the and other RFCs referenced therein. Although mitigations for the
current known vulnerabilities have been developed, any future issues current known vulnerabilities have been developed, any future issues
discovered in old protocol versions might not be mitigated in older discovered in old protocol versions might not be mitigated in older
library versions when newer library versions do not support those old library versions when newer library versions do not support those old
protocols. protocols.
NIST for example have provided the following rationale, copied with NIST for example has provided the following rationale, copied with
permission from [NIST800-52r2], section 1.2 "History of TLS" (with permission from [NIST800-52r2], section 1.2 "History of TLS" (with
references changed for RFC formatting). references changed for RFC formatting).
TLS 1.1, specified in [RFC4346], was developed to address TLSv1.1, specified in [RFC4346], was developed to address
weaknesses discovered in TLS 1.0, primarily in the areas of weaknesses discovered in TLSv1.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
operation used by TLS. The handling of padding errors was altered operation used by TLS. The handling of padding errors was altered
to treat a padding error as a bad message authentication code, to treat a padding error as a bad message authentication code,
rather than a decryption failure. In addition, the TLS 1.1 RFC rather than a decryption failure. In addition, the TLSv1.1 RFC
acknowledges attacks on CBC mode that rely on the time to compute acknowledges attacks on CBC mode that rely on the time to compute
the message authentication code (MAC). The TLS 1.1 specification the message authentication code (MAC). The TLSv1.1 specification
states that to defend against such attacks, an implementation must states that to defend against such attacks, an implementation must
process records in the same manner regardless of whether padding process records in the same manner regardless of whether padding
errors exist. Further implementation considerations for CBC modes errors exist. Further implementation considerations for CBC modes
(which were not included in RFC4346 [RFC4346]) are discussed in (which were not included in RFC4346 [RFC4346]) are discussed in
Section 3.3.2. Section 3.3.2.
TLSv1.2, specified in RFC5246 [RFC5246], made several TLSv1.2, specified in RFC5246 [RFC5246], made several
cryptographic enhancements, particularly in the area of hash cryptographic enhancements, particularly in the area of hash
functions, with the ability to use or specify the SHA-2 family functions, with the ability to use or specify the SHA-2 family
algorithms for hash, MAC, and Pseudorandom Function (PRF) algorithms for hash, MAC, and Pseudorandom Function (PRF)
computations. TLSv1.2 also adds authenticated encryption with computations. TLSv1.2 also adds authenticated encryption with
associated data (AEAD) cipher suites. associated data (AEAD) cipher suites.
TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant TLSv1.3, specified in TLSv1.3 [RFC8446], represents a significant
change to TLS that aims to address threats that have arisen over change to TLS that aims to address threats that have arisen over
the years. Among the changes are a new handshake protocol, a new the years. Among the changes are a new handshake protocol, a new
key derivation process that uses the HMAC-based Extract-and-Expand key derivation process that uses the HMAC-based Extract-and-Expand
Key Derivation Function (HKDF), and the removal of cipher suites Key Derivation Function (HKDF), and the removal of cipher suites
that use static RSA or DH key exchanges, the CBC mode of that use static RSA or DH key exchanges, the CBC mode of
operation, or SHA-1. The list of extensions that can be used with operation, or SHA-1. The list of extensions that can be used with
TLS 1.3 has been reduced considerably. TLSv1.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 a SHA-1 hash or a not appreciably stronger concatenation made using a SHA-1 hash or a not appreciably stronger concatenation
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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)", which Security (TLS) and Datagram Transport Layer Security (DTLS)", which
is the most recent best practice document for implementing TLS and is the most recent best practice document for implementing TLS and
was based on TLSv1.2. At the time of publication, TLSv1.0 and was based on TLSv1.2. At the time of publication, TLSv1.0 and
TLSv1.1 had not yet been deprecated. As such, this document is TLSv1.1 had not yet been deprecated. As such, BCP195 is called out
called out specifically to update text implementing the deprecation 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 8, line 39 skipping to change at page 8, line 39
suites. suites.
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. 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 TLSv1.1 has been obsolete since the publication of RFC 5246 in
2008, and DTLSv1.0 has been obsolete since the publication of RFC
6347 in 2012, there may remain some systems in operation that do not
support (D)TLSv1.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.
8. Security Considerations
This document deprecates two older TLS protocol versions and one This document deprecates two older TLS protocol versions and one
older DTLS protocol version for security reasons already described. older DTLS protocol version for security reasons already described.
The attack surface is reduced when there are a smaller number of The attack surface is reduced when there are a smaller number of
supported protocols and fallback options are removed. supported protocols and fallback options are removed.
8. Acknowledgements 9. 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: Michael Ackermann, David Benjamin, David
Viktor Dukhovni, Julien Elie, Gary Gapinski, Alessandro Ghedini, Black, Deborah Brungard, Alan DeKok, Viktor Dukhovni, Julien Elie,
Jeremy Harris, James Hodgkinson, Russ Housley, Hubert Kario, Benjamin Adrian Farrelll, Gary Gapinski, Alessandro Ghedini, Peter Gutmann,
Kaduk, John Mattsson, Eric Mill, Yoav Nir, Andrei Popov, Eric Jeremy Harris, Nick Hilliard, James Hodgkinson, Russ Housley, Hubert
Rescorla, Yaron Sheffer, Robert Sparks, Martin Thomson, Loganaden Kario, Benjamin Kaduk, John Klensin, Watson Ladd, Eliot Lear, Ted
Velvindron, and Jakub Wilk. Lemon, John Mattsson, Keith Moore, Tom Petch, Eric Mill, Yoav Nir,
Andrei Popov, Michael Richardson, Eric Rescorla, Rich Salz, Mohit
Sethi, Yaron Sheffer, Rob Sayre, Robert Sparks, Barbara Stark, Martin
Thomson, Sean Turner, Loganaden Velvindron, and Jakub Wilk.
[[Note to RFC editor: At least Julien Elie's name above should have [[Note to RFC editor: At least Julien Elie's name above should have
an accent on the first letter of the surname. Please fix that and an accent on the first letter of the surname. Please fix that and
any others needing a similar fix if you can, I'm not sure the tooling any others needing a similar fix if you can, I'm not sure the tooling
I have now allows that.]] I have now allows that.]]
9. IANA Considerations 10. IANA Considerations
[[This memo includes no request to IANA.]] [[This memo includes no request to IANA.]]
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>. <https://www.rfc-editor.org/info/rfc2246>.
skipping to change at page 16, line 18 skipping to change at page 16, line 30
[RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Transport over TCP", STD 69, RFC 5734, Transport over TCP", STD 69, RFC 5734,
DOI 10.17487/RFC5734, August 2009, DOI 10.17487/RFC5734, August 2009,
<https://www.rfc-editor.org/info/rfc5734>. <https://www.rfc-editor.org/info/rfc5734>.
[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS)
Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878,
May 2010, <https://www.rfc-editor.org/info/rfc5878>. May 2010, <https://www.rfc-editor.org/info/rfc5878>.
[RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
RFC 5953, DOI 10.17487/RFC5953, August 2010,
<https://www.rfc-editor.org/info/rfc5953>.
[RFC6042] Keromytis, A., "Transport Layer Security (TLS) [RFC6042] Keromytis, A., "Transport Layer Security (TLS)
Authorization Using KeyNote", RFC 6042, Authorization Using KeyNote", RFC 6042,
DOI 10.17487/RFC6042, October 2010, DOI 10.17487/RFC6042, October 2010,
<https://www.rfc-editor.org/info/rfc6042>. <https://www.rfc-editor.org/info/rfc6042>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
2011, <https://www.rfc-editor.org/info/rfc6176>. 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
<https://www.rfc-editor.org/info/rfc6353>.
[RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher
Suites to Transport Layer Security (TLS)", RFC 6367, Suites to Transport Layer Security (TLS)", RFC 6367,
DOI 10.17487/RFC6367, September 2011, DOI 10.17487/RFC6367, September 2011,
<https://www.rfc-editor.org/info/rfc6367>. <https://www.rfc-editor.org/info/rfc6367>.
[RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service [RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service
Boundaries and <mapping> Elements Based on the Location- Boundaries and <mapping> Elements Based on the Location-
to-Service Translation (LoST) Protocol", RFC 6739, to-Service Translation (LoST) Protocol", RFC 6739,
DOI 10.17487/RFC6739, October 2012, DOI 10.17487/RFC6739, October 2012,
<https://www.rfc-editor.org/info/rfc6739>. <https://www.rfc-editor.org/info/rfc6739>.
skipping to change at page 17, line 40 skipping to change at page 18, line 11
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
10.2. Informative References 11.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/transcript- https://www.mitls.org/downloads/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 SP800-52r2
skipping to change at page 22, line 9 skipping to change at page 22, line 9
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
Appendix A. Change Log Appendix A. Change Log
[[RFC editor: please remove this before publication.]] [[RFC editor: please remove this before publication.]]
From draft-ietf-tls-oldversions-deprecate-09 to draft-ietf-tls-
oldversions-deprecate-10:
o We missed adding change logs for a few versions, but since -09 was
the one that underwent IETF last call, and there was some
discussion, we figured it'd be good to mention substantive changes
here.
o Added Ben's suggested text for "operational considerations"
following extensive last call discussion.
o Re-checked the references to RFC 4347 after Tom Petch noticed we
missed a couple. Added RFCs 5953 and 6353 to the list here. All
others were in already.
o Fixed various typos and ack'd those who engaged a bit in the IETF
LC discussion. (If we missed you and you want to be added, or if
you'd rather not be mentioned, just ping the authors.)
From draft-ietf-tls-oldversions-deprecate-05 to draft-ietf-tls- From draft-ietf-tls-oldversions-deprecate-05 to draft-ietf-tls-
oldversions-deprecate-06: oldversions-deprecate-06:
o Fixed "yaleman" ack. o Fixed "yaleman" ack.
o Added RFC6614 to UPDATEs list. o Added RFC6614 to UPDATEs list.
o per preliminary AD review: o per preliminary AD review:
* Remove references from abstract * Remove references from abstract
* s/primary technical reasons/technical reasons/ * s/primary technical reasons/technical reasons/
* Add rfc7030 to 1.1 * Add rfc7030 to 1.1
 End of changes. 27 change blocks. 
61 lines changed or deleted 112 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/