idnits 2.17.1 draft-moriarty-tls-oldversions-diediedie-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2246], [RFC4346]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC4346, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7525, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2018) is 2132 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-tls-iana-registry-updates' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC7568' is defined on line 409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Moriarty 3 Internet-Draft Dell EMC 4 Updates: [[List TBD]] (if approved) S. Farrell 5 Intended status: Standards Track Trinity College Dublin 6 Expires: December 20, 2018 June 18, 2018 8 Deprecating TLSv1.0 and TLSv1.1 9 draft-moriarty-tls-oldversions-diediedie-00 11 Abstract 13 This document [if approved] formally deprecates Transport Layer 14 Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves 15 these documents to the historic state. These versions lack support 16 for current and recommended cipher suites, and various government and 17 industry profiiles of applications using TLS now mandate avoiding 18 these old TLS versions. TLSv1.2 has been the recommended version for 19 IETF protocols since 2008, providing sufficient time to transition 20 away from older versions. Products having to support older versions 21 increase the attack surface unnecessarily and increase opportunities 22 for misconfigurations. Supporting these older versions also requires 23 additional effort for library and product maintenance. 25 This document updates the backward compatibility sections of TLS RFCs 26 [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This 27 document also updates RFC 7525. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 20, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 3 66 2.1. NIST 800-52r2 . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Usage and Support . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 5 69 5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 6 70 6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 11.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 [[Text in double-square brackets, like this, is commentary intended 84 to be fixed as the draft evolves. You're already seen that we need 85 to figure out the list of RFCs that this'd update in the abstract.]] 87 Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 88 [RFC4346] were superceded by TLSv1.2 [RFC5246] in 2008, which has now 89 itself been superceded by TLSv1.3 [I-D.ietf-tls-tls13]. It is 90 therefore timely to further deprecate these old versions. The 91 expection is that TLSv1.2 will continue to be used for many years 92 alongside TLSv1.3. 94 TLSv1.1 and TLSv1.0 are also actively being deprecated in accordance 95 with guidance from government agencies (e.g. NIST SP 80052r2 96 [NIST800-52r2]) and industry consortia such as the Payment Card 97 Industry Association (PCI) [PCI-TLS1]. 99 The primary technical reasons for deprecating these versions include: 101 o They require implementation of older cipher suites that are no 102 longer desirable for cryptographic reasons, e.g. TLSv1.0 makes 103 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement 105 o Lack of support for current recommended cipher suites, especially 106 using AEAD ciphers which are not supported prior to TLS 1.2 108 o Support for four protocol versions increases the likelihood of 109 misconfiguration 111 o At least one widely-used library has plans to drop TLSv1.1 and 112 TLSv1.0 support in upcoming releases; products using such 113 libraries would need to use older versions of the libraries to 114 support TLSv1.0 and TLSv1.1, which is clearly undesirable 116 Deprecation of these versions is intended to assist developers as 117 additional justification to no longer support older TLS versions and 118 to migrate to a minimum of TLSv1.2. Deprecation also assists product 119 teams with phasing out support for the older versions to reduce the 120 attack surface and the scope of maintenance for protocols in their 121 offerings. 123 [[This draft is being written now so that the TLS WG chairs can just 124 hit the "publication requested" button as soon as there is WG 125 consensus to deprecate these ancient versions of TLS. The authors 126 however think that deprecation now is timely.]] 128 1.1. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Support for Deprecation 138 Industry is actively following guidance provided by NIST and the PCI 139 Council deprecating TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 140 should remain a minimum baseline for TLS support at this time. 142 Specific details on attacks against TLSv1.0 and TLSv1.1 as well as 143 their mitigations are provided in NIST SP800-52r2 [NIST800-52r2] and 144 referenced RFCs. Although the attacks have been mitigated, if 145 support is dropped for future library releases for these versions, it 146 is unlikely attacks found going forward will be mitigated in older 147 library releases. 149 They have provided the following rationale. 151 2.1. NIST 800-52r2 153 The following text is copied with permission from NIST SP800-52r2 154 [NIST800-52r2] section 1.2 History of TLS. 156 TLS 1.1, specified in [RFC4346], was developed to address weaknesses 157 discovered in TLS 1.0, primarily in the areas of initialization 158 vector selection and padding error processing. Initialization 159 vectors were made explicit to prevent a certain class of attacks on 160 the Cipher Block Chaining (CBC) mode of operation used by TLS. The 161 handling of padding errors was altered to treat a padding error as a 162 bad message authentication code, rather than a decryption failure. 163 In addition, the TLS 1.1 RFC acknowledges attacks on CBC mode that 164 rely on the time to compute the message authentication code (MAC). 165 The TLS 1.1 specification states that to defend against such attacks, 166 an implementation must process records in the same manner regardless 167 of whether padding errors exist. Further implementation 168 considerations for CBC modes (which were not included in RFC4346 169 [RFC4346]) are discussed in Section 3.3.2. 171 TLS 1.2, specified in RFC5246 [RFC5246], made several cryptographic 172 enhancements, particularly in the area of hash functions, with the 173 ability to use or specify the SHA-2 family algorithms for hash, MAC, 174 and Pseudorandom Function (PRF) computations. TLS 1.2 also adds 175 authenticated encryption with associated data (AEAD) cipher suites. 177 TLS 1.3, specified in TLSv1.3 [I-D.ietf-tls-tls13], represents a 178 significant change to TLS that aims to address threats that have 179 arisen over the years. Among the changes are a new handshake 180 protocol, a new key derivation process that uses the HMAC-based 181 Extract-and-Expand Key Derivation Function (HKDF), and the removal of 182 cipher suites that use static RSA or DH key exchanges, the CBC mode 183 of operation, or SHA-1. The list of extensions that can be used with 184 TLS 1.3 has been reduced considerably. 186 3. Usage and Support 188 [[This section can be removed upon publication.]] 190 Usage statistics for TLSv1.0 and TLSv1.1 vary slightly, but are in 191 general very low already and soon to decline further with the 192 impending PCI deadline to migrate off of TLSv1.0 by June 30, 2018. 193 As of January 2018, Stackexchange [StackExchange] quoted 4 percent of 194 browsers using TLSv1.0. 196 The Alexa Top 1 Million Analysis [Alexa] from February 2018 shows 197 that for the sites surveyed, the vast majority support TLSv1.2 (98.9 198 percent), with a mere 0.8 percent using TLSv1.0 and an even smaller 199 percentage using TLSv1.1. 201 Support for TLSv1.0 has been removed or will be by July 2018 from the 202 following standards, products, and services: 204 o 3GPP 5G 206 o [[Numerous web sites...]] 208 o CloudFare [CloudFlare] 210 o Amazon Elastic Load Balancing [Amazon] 212 o GitHub [GIT] 214 Many web sites have taken the action of including the deprecation of 215 TLSv1.1 into their plans for deprecating TLSv1.0 for the PCI council 216 deadline. Support for TLSv1.1 has been removed or will be by July 217 2018 from the following standards, products, and services: 219 o 3GPP 5G Release 16 221 o GitHub [GIT] 223 o Amazon Elastic Load Balancing [Amazon] 225 o CloudFare [CloudFlare] 227 o [[Numerous web sites...]] 229 4. Do Not Use TLSv1.0 231 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of 232 TLS MUST NOT be permitted. 234 Any version of TLS is more secure then TLSv1.0 and can be configured 235 to prevent interception, though the highest version available is 236 preferable. 238 Pragmatically, clients MUST NOT send a ClientHello with 239 ClientHello.client_version set to {03,01}. Similarly, servers MUST 240 NOT send a ServerHello with ServerHello.server_version set to 241 {03,01}. Any party receiving a Hello message with the protocol 242 version set to {03,01} MUST respond with a "protocol_version" alert 243 message and close the connection. 245 Historically, TLS specifications were not clear on what the record 246 layer version number (TLSPlaintext.version) could contain when 247 sending ClientHello. Appendix E of [RFC5246] notes that 248 TLSPlaintext.version could be selected to maximize interoperability, 249 though no definitive value is identified as ideal. That guidance is 250 still applicable; therefore, TLS servers MUST accept any value 251 {03,XX} (including {03,00}) as the record layer version number for 252 ClientHello, but they MUST NOT negotiate TLSv1.0. 254 5. Do Not Use TLSv1.1 256 TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of 257 TLS MUST NOT be permitted. 259 Pragmatically, clients MUST NOT send a ClientHello with 260 ClientHello.client_version set to {03,02}. Similarly, servers MUST 261 NOT send a ServerHello with ServerHello.server_version set to 262 {03,02}. Any party receiving a Hello message with the protocol 263 version set to {03,02} MUST respond with a "protocol_version" alert 264 message and close the connection. 266 Any newer version of TLS is more secure then TLSv1.1 and can be 267 configured to prevent interception, though the highest version 268 available is preferable. Support for TLSv1.1 is dwindling in 269 libraries and will impact security going forward if mitagations for 270 attacks cannot be easily addressed and supported in older libraries. 272 Historically, TLS specifications were not clear on what the record 273 layer version number (TLSPlaintext.version) could contain when 274 sending ClientHello. Appendix E of [RFC5246] notes that 275 TLSPlaintext.version could be selected to maximize interoperability, 276 though no definitive value is identified as ideal. That guidance is 277 still applicable; therefore, TLS servers MUST accept any value 278 {03,XX} (including {03,00}) as the record layer version number for 279 ClientHello, but they MUST NOT negotiate TLSv1.1. 281 6. Updates to RFC7525 283 [[Since RFC7525 is BCP195, there'll probably be some process-fun to 284 do an update of that. Formally, it may be that this document becomes 285 a new part of BCP195 I guess, but we can figure that out with chairs 286 and ADs.]] 288 This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to 289 MUST NOT as follows: 291 o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 293 Rationale: TLS 1.0 (published in 1999) does not support many 294 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 295 record Initialization Vector (IV) for CBC-based cipher suites and 296 does not warn against common padding errors. 298 o Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 300 Rationale: TLS 1.1 (published in 2006) is a security improvement 301 over TLS 1.0 but still does not support certain stronger cipher 302 suites. 304 This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to 305 MUST NOT as follows: 307 o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347]. 309 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 311 7. Security Considerations 313 This document deprecates two older protocol versions for security 314 reasons already described. The attack surface is reduced when there 315 are a smaller number of supported protocols and fallback options are 316 removed. 318 8. Acknowledgements 320 Thank you to those that reviewed and improved this document, 321 including Yoav Nir, Russ Housley, and David Black. 323 9. IANA Considerations 325 [[This memo includes no request to IANA.]] 327 10. Contributors 329 11. References 331 11.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 339 RFC 2246, DOI 10.17487/RFC2246, January 1999, 340 . 342 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 343 (TLS) Protocol Version 1.1", RFC 4346, 344 DOI 10.17487/RFC4346, April 2006, 345 . 347 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 348 "Recommendations for Secure Use of Transport Layer 349 Security (TLS) and Datagram Transport Layer Security 350 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 351 2015, . 353 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 354 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 355 May 2017, . 357 11.2. Informative References 359 [Alexa] Will be deleted before publication, "The Alexa Top 1 360 Million Analysis https://scotthelme.co.uk/ 361 alexa-top-1-million-analysis-february-2018/", 2018. 363 [Amazon] CloudFlare, "Amazon Elastic Load Balancing Support 364 Deprecated TLSv1.0 and TLSv1.1 https://aws.amazon.com/ 365 about-aws/whats-new/2017/02/elastic-load-balancing- 366 support-for-tls-1-1-and-tls-1-2-pre-defined-security- 367 policies/", 2017. 369 [CloudFlare] 370 CloudFlare, "CloudFlare Deprecated TLSv1.0 and TLSv1.1 371 https://blog.cloudflare.com/deprecating-old-tls-versions- 372 on-cloudflare-dashboard-and-api/", 2018. 374 [GIT] GitHub, "GitHub Deprecates TLSv1.0 and TLSv1.1 375 https://githubengineering.com/crypto-removal-notice/", 376 2018. 378 [I-D.ietf-tls-iana-registry-updates] 379 Salowey, J. and S. Turner, "IANA Registry Updates for 380 Transport Layer Security (TLS) and Datagram Transport 381 Layer Security (DTLS)", draft-ietf-tls-iana-registry- 382 updates-05 (work in progress), May 2018. 384 [I-D.ietf-tls-tls13] 385 Rescorla, E., "The Transport Layer Security (TLS) Protocol 386 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 387 March 2018. 389 [NIST800-52r2] 390 National Institute of Standards and Technology, "NIST 391 SP800-52r2 https://csrc.nist.gov/CSRC/media/Publications/ 392 sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf", 393 2018. 395 [PCI-TLS1] 396 PCI Security Standards Council, "Migrating from SSL and 397 Early TLS https://www.pcisecuritystandards.org/documents/ 398 Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf", 2016. 400 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 401 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 402 . 404 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 405 (TLS) Protocol Version 1.2", RFC 5246, 406 DOI 10.17487/RFC5246, August 2008, 407 . 409 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 410 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 411 DOI 10.17487/RFC7568, June 2015, 412 . 414 [StackExchange] 415 StackExchange - will be deleted before publication, 416 "Stackexchange 417 https://security.stackexchange.com/questions/177182/is- 418 there-a-list-of-old-browsers-that-only-support-tls-1-0", 419 2018. 421 Appendix A. Change Log 423 Note to RFC Editor: if this document does not obsolete an existing 424 RFC, please remove this appendix before publication as an RFC. 426 Authors' Addresses 428 Kathleen Moriarty 429 Dell EMC 430 176 South Street 431 Hopkinton 432 United States 434 EMail: Kathleen.Moriarty.ietf@gmail.com 436 Stephen Farrell 437 Trinity College Dublin 438 Dublin 2 439 Ireland 441 Phone: +353-1-896-2354 442 EMail: stephen.farrell@cs.tcd.ie