idnits 2.17.1 draft-ietf-tls-oldversions-deprecate-01.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 draft header indicates that this document updates RFC7568, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8422, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7465, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7507, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7562, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8465, but the abstract doesn't seem to mention this, which it should. -- 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 (November 8, 2018) is 1989 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) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Downref: Normative reference to an Informational RFC: RFC 3568 ** Downref: Normative reference to an Experimental RFC: RFC 3656 ** Downref: Normative reference to an Informational RFC: RFC 3871 ** Downref: Normative reference to an Informational RFC: RFC 3943 ** Downref: Normative reference to an Informational RFC: RFC 4097 ** Downref: Normative reference to an Informational RFC: RFC 4111 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Downref: Normative reference to an Experimental RFC: RFC 4531 ** Downref: Normative reference to an Experimental RFC: RFC 4540 ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Downref: Normative reference to an Informational RFC: RFC 4732 ** Downref: Normative reference to an Historic RFC: RFC 4743 ** Downref: Normative reference to an Historic RFC: RFC 4744 ** Downref: Normative reference to an Informational RFC: RFC 4823 ** Downref: Normative reference to an Informational RFC: RFC 4851 ** Downref: Normative reference to an Informational RFC: RFC 4964 ** Downref: Normative reference to an Informational RFC: RFC 5024 ** Downref: Normative reference to an Informational RFC: RFC 5054 ** Downref: Normative reference to an Informational RFC: RFC 5091 ** Downref: Normative reference to an Informational RFC: RFC 5158 ** Downref: Normative reference to an Informational RFC: RFC 5281 ** Downref: Normative reference to an Informational RFC: RFC 5422 ** Obsolete normative reference: RFC 5469 (Obsoleted by RFC 8996) ** Downref: Normative reference to an Experimental RFC: RFC 5878 ** Downref: Normative reference to an Informational RFC: RFC 6042 ** Downref: Normative reference to an Informational RFC: RFC 6367 ** Downref: Normative reference to an Experimental RFC: RFC 6739 ** Downref: Normative reference to an Informational RFC: RFC 7255 ** Obsolete normative reference: RFC 7507 (Obsoleted by RFC 8996) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 7562 ** Downref: Normative reference to an Informational RFC: RFC 8465 -- Obsolete informational reference (is this intentional?): RFC 3316 (Obsoleted by RFC 7066) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3734 (Obsoleted by RFC 4934) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 4132 (Obsoleted by RFC 5932) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 4507 (Obsoleted by RFC 5077) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 4934 (Obsoleted by RFC 5734) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 35 errors (**), 0 flaws (~~), 1 warning (==), 27 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: 8465 8422 7568 7562 7507 7465 S. Farrell 5 7255 7030 6750 6749 6739 6367 Trinity College Dublin 6 6176 6042 5878 5734 5469 5422 November 8, 2018 7 5364 5281 5263 5238 5216 5158 8 5091 5054 5049 5024 5023 5019 9 5018 4992 4976 4975 4964 4851 10 4823 4791 4785 4744 4743 4732 11 4712 4681 4680 4642 4616 4582 12 4540 4531 4513 4497 4279 4261 13 4235 4217 4168 4162 4111 4097 14 3983 3943 3903 3887 3871 3856 15 3767 3749 3656 3568 3552 3501 16 3470 3436 3329 3261 (if 17 approved) 18 Intended status: Standards Track 19 Expires: May 12, 2019 21 Deprecating TLSv1.0 and TLSv1.1 22 draft-ietf-tls-oldversions-deprecate-01 24 Abstract 26 This document, if approved, formally deprecates Transport Layer 27 Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves 28 these documents to the historic state. These versions lack support 29 for current and recommended cipher suites, and various government and 30 industry profiles of applications using TLS now mandate avoiding 31 these old TLS versions. TLSv1.2 has been the recommended version for 32 IETF protocols since 2008, providing sufficient time to transition 33 away from older versions. Products having to support older versions 34 increase the attack surface unnecessarily and increase opportunities 35 for misconfigurations. Supporting these older versions also requires 36 additional effort for library and product maintenance. 38 This document updates many RFCs that normatively refer to TLS1.0 or 39 TLS1.1 as described herein. This document also updates RFC 7525 and 40 hence is part of BCP195. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on May 12, 2019. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Updates . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 4 80 3. SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6 82 5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 6 83 6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 7 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 89 10.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 96 [RFC4346] were superceded by TLSv1.2 [RFC5246] in 2008, which has now 97 itself been superceded by TLSv1.3 [RFC8446]. It is therefore timely 98 to further deprecate these old versions. The expectation is that 99 TLSv1.2 will continue to be used for many years alongside TLSv1.3. 101 TLSv1.1 and TLSv1.0 are also actively being deprecated in accordance 102 with guidance from government agencies (e.g. NIST SP 80052r2 103 [NIST800-52r2]) and industry consortia such as the Payment Card 104 Industry Association (PCI) [PCI-TLS1]. 106 The primary technical reasons for deprecating these versions include: 108 o They require implementation of older cipher suites that are no 109 longer desirable for cryptographic reasons, e.g. TLSv1.0 makes 110 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement 111 o Lack of support for current recommended cipher suites, especially 112 using AEAD ciphers which are not supported prior to TLS 1.2. 113 Note: registry entries for no-longer-desirable ciphersuites remain 114 in the registries, but many TLS registries are being updated 115 through [RFC8447] which denotes such entries as "not recommended." 116 o Integrity of the handshake depends on SHA-1 hash 117 o Authentication of the peers depends on SHA-1 signatures 118 o Support for four protocol versions increases the likelihood of 119 misconfiguration 120 o At least one widely-used library has plans to drop TLSv1.1 and 121 TLSv1.0 support in upcoming releases; products using such 122 libraries would need to use older versions of the libraries to 123 support TLSv1.0 and TLSv1.1, which is clearly undesirable 125 Deprecation of these versions is intended to assist developers as 126 additional justification to no longer support older TLS versions and 127 to migrate to a minimum of TLSv1.2. Deprecation also assists product 128 teams with phasing out support for the older versions to reduce the 129 attack surface and the scope of maintenance for protocols in their 130 offerings. 132 1.1. Updates 134 This document updates these RFCs that normatively reference TLS1.0 or 135 TLS1.1 and have not been obsoleted: [RFC8465] [RFC8422] [RFC7568] 136 [RFC7562] [RFC7507] [RFC7465] [RFC7255] [RFC7030] [RFC6750] [RFC6749] 137 [RFC6739] [RFC6367] [RFC6176] [RFC6042] [RFC5878] [RFC5734] [RFC5469] 138 [RFC5422] [RFC5364] [RFC5281] [RFC5263] [RFC5238] [RFC5216] [RFC5158] 139 [RFC5091] [RFC5054] [RFC5049] [RFC5024] [RFC5023] [RFC5019] [RFC5018] 140 [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC4851] [RFC4823] [RFC4791] 142 [RFC4785] [RFC4744] [RFC4743] [RFC4732] [RFC4712] [RFC4681] [RFC4680] 143 [RFC4642] [RFC4616] [RFC4582] [RFC4540] [RFC4531] [RFC4513] [RFC4497] 144 [RFC4279] [RFC4261] [RFC4235] [RFC4217] [RFC4168] [RFC4162] [RFC4111] 145 [RFC4097] [RFC3983] [RFC3943] [RFC3903] [RFC3887] [RFC3871] [RFC3856] 146 [RFC3767] [RFC3749] [RFC3656] [RFC3568] [RFC3552] [RFC3501] [RFC3470] 147 [RFC3436] [RFC3329] [RFC3261] 149 In addition these RFCs normatively refer to TLS1.0 or TLS1.1 and have 150 been obsoleted, or informatively refer to TLS1.0 or TLS1.1: [RFC5101] 151 [RFC5081] [RFC5077] [RFC4934] [RFC4572] [RFC4507] [RFC4492] [RFC4366] 152 [RFC4347] [RFC4244] [RFC4132] [RFC3920] [RFC3734] [RFC3588] [RFC3546] 153 [RFC3489] [RFC3316] 155 1.2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119] [RFC8174] when, and only when, they appear in all 161 capitals, as shown here. 163 2. Support for Deprecation 165 Industry has actively followed guidance provided by NIST and the PCI 166 Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 167 should remain a minimum baseline for TLS support at this time. 169 Specific details on attacks against TLSv1.0 and TLSv1.1 as well as 170 their mitigations are provided in NIST SP800-52r2 [NIST800-52r2], RFC 171 7457 [RFC7457] and other referenced RFCs. Although the attacks have 172 been mitigated, if support is dropped for future library releases for 173 these versions, it is unlikely attacks found going forward will be 174 mitigated in older library releases. 176 NIST for example have provided the following rationale, copied with 177 permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History 178 of TLS" (with references changed for RFC formatting). 180 TLS 1.1, specified in [RFC4346], was developed to address 181 weaknesses discovered in TLS 1.0, primarily in the areas of 182 initialization vector selection and padding error processing. 183 Initialization vectors were made explicit to prevent a certain 184 class of attacks on the Cipher Block Chaining (CBC) mode of 185 operation used by TLS. The handling of padding errors was altered 186 to treat a padding error as a bad message authentication code, 187 rather than a decryption failure. In addition, the TLS 1.1 RFC 188 acknowledges attacks on CBC mode that rely on the time to compute 189 the message authentication code (MAC). The TLS 1.1 specification 190 states that to defend against such attacks, an implementation must 191 process records in the same manner regardless of whether padding 192 errors exist. Further implementation considerations for CBC modes 193 (which were not included in RFC4346 [RFC4346]) are discussed in 194 Section 3.3.2. 196 TLS 1.2, specified in RFC5246 [RFC5246], made several 197 cryptographic enhancements, particularly in the area of hash 198 functions, with the ability to use or specify the SHA-2 family 199 algorithms for hash, MAC, and Pseudorandom Function (PRF) 200 computations. TLS 1.2 also adds authenticated encryption with 201 associated data (AEAD) cipher suites. 203 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant 204 change to TLS that aims to address threats that have arisen over 205 the years. Among the changes are a new handshake protocol, a new 206 key derivation process that uses the HMAC-based Extract-and-Expand 207 Key Derivation Function (HKDF), and the removal of cipher suites 208 that use static RSA or DH key exchanges, the CBC mode of 209 operation, or SHA-1. The list of extensions that can be used with 210 TLS 1.3 has been reduced considerably. 212 The Canadian government treasury board have also mandated that these 213 old versions of TLS not be used. [Canada] 215 Various companies and web sites have announced plans to deprecate 216 these old versions of TLS. 218 3. SHA-1 220 The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 221 hash of the exchanged messages. This makes it possible to perform a 222 downgrade attack on the handshake by an attacker able to perform 2^77 223 operations, well below the acceptable modern security margin. 225 Similarly, the authentication of the handshake depends on signatures 226 made using SHA-1 hash or a not stronger concatenation of MD-5 and 227 SHA-1 hashes, allowing the attacker to impersonate a server when it 228 is able to break the severely weakened SHA-1 hash. 230 Neither TLSv1.0 nor TLSv1.1 allow the peers to select a stronger hash 231 for signatures in the ServerKeyExchange or CertificateVerify 232 messages, making the only upgrade path the use of a newer protocol 233 version. 235 See [Bhargavan2016] for additional detail. 237 4. Do Not Use TLSv1.0 239 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of 240 TLS MUST NOT be permitted. 242 Any other version of TLS is more secure than TLSv1.0. TLSv1.0 can be 243 configured to prevent interception, though using the highest version 244 available is preferable. 246 Pragmatically, clients MUST NOT send a ClientHello with 247 ClientHello.client_version set to {03,01}. Similarly, servers MUST 248 NOT send a ServerHello with ServerHello.server_version set to 249 {03,01}. Any party receiving a Hello message with the protocol 250 version set to {03,01} MUST respond with a "protocol_version" alert 251 message and close the connection. 253 Historically, TLS specifications were not clear on what the record 254 layer version number (TLSPlaintext.version) could contain when 255 sending ClientHello. Appendix E of [RFC5246] notes that 256 TLSPlaintext.version could be selected to maximize interoperability, 257 though no definitive value is identified as ideal. That guidance is 258 still applicable; therefore, TLS servers MUST accept any value 259 {03,XX} (including {03,00}) as the record layer version number for 260 ClientHello, but they MUST NOT negotiate TLSv1.0. 262 5. Do Not Use TLSv1.1 264 TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of 265 TLS MUST NOT be permitted. 267 Pragmatically, clients MUST NOT send a ClientHello with 268 ClientHello.client_version set to {03,02}. Similarly, servers MUST 269 NOT send a ServerHello with ServerHello.server_version set to 270 {03,02}. Any party receiving a Hello message with the protocol 271 version set to {03,02} MUST respond with a "protocol_version" alert 272 message and close the connection. 274 Any newer version of TLS is more secure than TLSv1.1. TLSv1.1 can be 275 configured to prevent interception, though using the highest version 276 available is preferable. Support for TLSv1.1 is dwindling in 277 libraries and will impact security going forward if mitigations for 278 attacks cannot be easily addressed and supported in older libraries. 280 Historically, TLS specifications were not clear on what the record 281 layer version number (TLSPlaintext.version) could contain when 282 sending ClientHello. Appendix E of [RFC5246] notes that 283 TLSPlaintext.version could be selected to maximize interoperability, 284 though no definitive value is identified as ideal. That guidance is 285 still applicable; therefore, TLS servers MUST accept any value 286 {03,XX} (including {03,00}) as the record layer version number for 287 ClientHello, but they MUST NOT negotiate TLSv1.1. 289 6. Updates to RFC7525 291 This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to 292 MUST NOT as follows: 294 o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 296 Rationale: TLS 1.0 (published in 1999) does not support many 297 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 298 record Initialization Vector (IV) for CBC-based cipher suites and 299 does not warn against common padding errors. 301 o Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 303 Rationale: TLS 1.1 (published in 2006) is a security improvement 304 over TLS 1.0 but still does not support certain stronger cipher 305 suites. 307 This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to 308 MUST NOT as follows: 310 o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347]. 312 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 314 7. Security Considerations 316 This document deprecates two older protocol versions for security 317 reasons already described. The attack surface is reduced when there 318 are a smaller number of supported protocols and fallback options are 319 removed. 321 8. Acknowledgements 323 Thanks to those that provided usage data, reviewed and/or improved 324 this document, including: David Benjamin, David Black, Viktor 325 Dukhovni, Alessandro Ghedini, Jeremy Harris, Russ Housley, Hubert 326 Kario, Loganaden Velvindron, Eric Mill, Yoav Nir, Andrei Popov, Eric 327 Rescorla, Yaron Sheffer, https://github.com/yaleman, and Jakub Wilk. 329 9. IANA Considerations 331 [[This memo includes no request to IANA.]] 333 10. References 335 10.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, 339 DOI 10.17487/RFC2119, March 1997, 340 . 342 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 343 RFC 2246, DOI 10.17487/RFC2246, January 1999, 344 . 346 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 347 A., Peterson, J., Sparks, R., Handley, M., and E. 348 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 349 DOI 10.17487/RFC3261, June 2002, 350 . 352 [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 353 Haukka, "Security Mechanism Agreement for the Session 354 Initiation Protocol (SIP)", RFC 3329, 355 DOI 10.17487/RFC3329, January 2003, 356 . 358 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 359 Layer Security over Stream Control Transmission Protocol", 360 RFC 3436, DOI 10.17487/RFC3436, December 2002, 361 . 363 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 364 the Use of Extensible Markup Language (XML) within IETF 365 Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, 366 January 2003, . 368 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 369 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 370 . 372 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 373 Text on Security Considerations", BCP 72, RFC 3552, 374 DOI 10.17487/RFC3552, July 2003, 375 . 377 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 378 Content Network (CN) Request-Routing Mechanisms", 379 RFC 3568, DOI 10.17487/RFC3568, July 2003, 380 . 382 [RFC3656] Siemborski, R., "The Mailbox Update (MUPDATE) Distributed 383 Mailbox Database Protocol", RFC 3656, 384 DOI 10.17487/RFC3656, December 2003, 385 . 387 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 388 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 389 2004, . 391 [RFC3767] Farrell, S., Ed., "Securely Available Credentials 392 Protocol", RFC 3767, DOI 10.17487/RFC3767, June 2004, 393 . 395 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 396 Initiation Protocol (SIP)", RFC 3856, 397 DOI 10.17487/RFC3856, August 2004, 398 . 400 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 401 Large Internet Service Provider (ISP) IP Network 402 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 403 2004, . 405 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 406 DOI 10.17487/RFC3887, September 2004, 407 . 409 [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) 410 Extension for Event State Publication", RFC 3903, 411 DOI 10.17487/RFC3903, October 2004, 412 . 414 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 415 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 416 DOI 10.17487/RFC3943, November 2004, 417 . 419 [RFC3983] Newton, A. and M. Sanz, "Using the Internet Registry 420 Information Service (IRIS) over the Blocks Extensible 421 Exchange Protocol (BEEP)", RFC 3983, DOI 10.17487/RFC3983, 422 January 2005, . 424 [RFC4097] Barnes, M., Ed., "Middlebox Communications (MIDCOM) 425 Protocol Evaluation", RFC 4097, DOI 10.17487/RFC4097, June 426 2005, . 428 [RFC4111] Fang, L., Ed., "Security Framework for Provider- 429 Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 430 DOI 10.17487/RFC4111, July 2005, 431 . 433 [RFC4162] Lee, H., Yoon, J., and J. Lee, "Addition of SEED Cipher 434 Suites to Transport Layer Security (TLS)", RFC 4162, 435 DOI 10.17487/RFC4162, August 2005, 436 . 438 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 439 Stream Control Transmission Protocol (SCTP) as a Transport 440 for the Session Initiation Protocol (SIP)", RFC 4168, 441 DOI 10.17487/RFC4168, October 2005, 442 . 444 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 445 DOI 10.17487/RFC4217, October 2005, 446 . 448 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 449 INVITE-Initiated Dialog Event Package for the Session 450 Initiation Protocol (SIP)", RFC 4235, 451 DOI 10.17487/RFC4235, November 2005, 452 . 454 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 455 Service (COPS) Over Transport Layer Security (TLS)", 456 RFC 4261, DOI 10.17487/RFC4261, December 2005, 457 . 459 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 460 Ciphersuites for Transport Layer Security (TLS)", 461 RFC 4279, DOI 10.17487/RFC4279, December 2005, 462 . 464 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 465 (TLS) Protocol Version 1.1", RFC 4346, 466 DOI 10.17487/RFC4346, April 2006, 467 . 469 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 470 "Interworking between the Session Initiation Protocol 471 (SIP) and QSIG", BCP 117, RFC 4497, DOI 10.17487/RFC4497, 472 May 2006, . 474 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 475 (LDAP): Authentication Methods and Security Mechanisms", 476 RFC 4513, DOI 10.17487/RFC4513, June 2006, 477 . 479 [RFC4531] Zeilenga, K., "Lightweight Directory Access Protocol 480 (LDAP) Turn Operation", RFC 4531, DOI 10.17487/RFC4531, 481 June 2006, . 483 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 484 Middlebox Configuration (SIMCO) Protocol Version 3.0", 485 RFC 4540, DOI 10.17487/RFC4540, May 2006, 486 . 488 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 489 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 490 November 2006, . 492 [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 493 Security Layer (SASL) Mechanism", RFC 4616, 494 DOI 10.17487/RFC4616, August 2006, 495 . 497 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 498 Transport Layer Security (TLS) with Network News Transfer 499 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 500 2006, . 502 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 503 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 504 . 506 [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User 507 Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, 508 October 2006, . 510 [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., 511 and Y. Kim, "Transport Mappings for Real-time Application 512 Quality-of-Service Monitoring (RAQMON) Protocol Data Unit 513 (PDU)", RFC 4712, DOI 10.17487/RFC4712, October 2006, 514 . 516 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 517 Denial-of-Service Considerations", RFC 4732, 518 DOI 10.17487/RFC4732, December 2006, 519 . 521 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 522 Protocol (SOAP)", RFC 4743, DOI 10.17487/RFC4743, December 523 2006, . 525 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 526 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 527 DOI 10.17487/RFC4744, December 2006, 528 . 530 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 531 Ciphersuites with NULL Encryption for Transport Layer 532 Security (TLS)", RFC 4785, DOI 10.17487/RFC4785, January 533 2007, . 535 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 536 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 537 DOI 10.17487/RFC4791, March 2007, 538 . 540 [RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- 541 to-Peer Business Data Interchange over the Internet", 542 RFC 4823, DOI 10.17487/RFC4823, April 2007, 543 . 545 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 546 Flexible Authentication via Secure Tunneling Extensible 547 Authentication Protocol Method (EAP-FAST)", RFC 4851, 548 DOI 10.17487/RFC4851, May 2007, 549 . 551 [RFC4964] Allen, A., Ed., Holm, J., and T. Hallin, "The P-Answer- 552 State Header Extension to the Session Initiation Protocol 553 for the Open Mobile Alliance Push to Talk over Cellular", 554 RFC 4964, DOI 10.17487/RFC4964, September 2007, 555 . 557 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 558 "The Message Session Relay Protocol (MSRP)", RFC 4975, 559 DOI 10.17487/RFC4975, September 2007, 560 . 562 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 563 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 564 DOI 10.17487/RFC4976, September 2007, 565 . 567 [RFC4992] Newton, A., "XML Pipelining with Chunks for the Internet 568 Registry Information Service", RFC 4992, 569 DOI 10.17487/RFC4992, August 2007, 570 . 572 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 573 Floor Control Protocol (BFCP)", RFC 5018, 574 DOI 10.17487/RFC5018, September 2007, 575 . 577 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 578 Certificate Status Protocol (OCSP) Profile for High-Volume 579 Environments", RFC 5019, DOI 10.17487/RFC5019, September 580 2007, . 582 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 583 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 584 October 2007, . 586 [RFC5024] Friend, I., "ODETTE File Transfer Protocol 2.0", RFC 5024, 587 DOI 10.17487/RFC5024, November 2007, 588 . 590 [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, Ed., 591 "Applying Signaling Compression (SigComp) to the Session 592 Initiation Protocol (SIP)", RFC 5049, 593 DOI 10.17487/RFC5049, December 2007, 594 . 596 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 597 "Using the Secure Remote Password (SRP) Protocol for TLS 598 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 599 2007, . 601 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 602 Standard (IBCS) #1: Supersingular Curve Implementations of 603 the BF and BB1 Cryptosystems", RFC 5091, 604 DOI 10.17487/RFC5091, December 2007, 605 . 607 [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", 608 RFC 5158, DOI 10.17487/RFC5158, March 2008, 609 . 611 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 612 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 613 March 2008, . 615 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 616 the Datagram Congestion Control Protocol (DCCP)", 617 RFC 5238, DOI 10.17487/RFC5238, May 2008, 618 . 620 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 621 Khartabil, "Session Initiation Protocol (SIP) Extension 622 for Partial Notification of Presence Information", 623 RFC 5263, DOI 10.17487/RFC5263, September 2008, 624 . 626 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 627 Protocol Tunneled Transport Layer Security Authenticated 628 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 629 DOI 10.17487/RFC5281, August 2008, 630 . 632 [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup 633 Language (XML) Format Extension for Representing Copy 634 Control Attributes in Resource Lists", RFC 5364, 635 DOI 10.17487/RFC5364, October 2008, 636 . 638 [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, 639 "Dynamic Provisioning Using Flexible Authentication via 640 Secure Tunneling Extensible Authentication Protocol (EAP- 641 FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009, 642 . 644 [RFC5469] Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport 645 Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469, 646 February 2009, . 648 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 649 Transport over TCP", STD 69, RFC 5734, 650 DOI 10.17487/RFC5734, August 2009, 651 . 653 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 654 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 655 May 2010, . 657 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 658 Authorization Using KeyNote", RFC 6042, 659 DOI 10.17487/RFC6042, October 2010, 660 . 662 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 663 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 664 2011, . 666 [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher 667 Suites to Transport Layer Security (TLS)", RFC 6367, 668 DOI 10.17487/RFC6367, September 2011, 669 . 671 [RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service 672 Boundaries and Elements Based on the Location- 673 to-Service Translation (LoST) Protocol", RFC 6739, 674 DOI 10.17487/RFC6739, October 2012, 675 . 677 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 678 RFC 6749, DOI 10.17487/RFC6749, October 2012, 679 . 681 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 682 Framework: Bearer Token Usage", RFC 6750, 683 DOI 10.17487/RFC6750, October 2012, 684 . 686 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 687 "Enrollment over Secure Transport", RFC 7030, 688 DOI 10.17487/RFC7030, October 2013, 689 . 691 [RFC7255] Allen, A., Ed., "Using the International Mobile station 692 Equipment Identity (IMEI) Uniform Resource Name (URN) as 693 an Instance ID", RFC 7255, DOI 10.17487/RFC7255, May 2014, 694 . 696 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 697 DOI 10.17487/RFC7465, February 2015, 698 . 700 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 701 Suite Value (SCSV) for Preventing Protocol Downgrade 702 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 703 . 705 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 706 "Recommendations for Secure Use of Transport Layer 707 Security (TLS) and Datagram Transport Layer Security 708 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 709 2015, . 711 [RFC7562] Thakore, D., "Transport Layer Security (TLS) Authorization 712 Using Digital Transmission Content Protection (DTCP) 713 Certificates", RFC 7562, DOI 10.17487/RFC7562, July 2015, 714 . 716 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 717 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 718 DOI 10.17487/RFC7568, June 2015, 719 . 721 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 722 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 723 May 2017, . 725 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 726 Curve Cryptography (ECC) Cipher Suites for Transport Layer 727 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 728 DOI 10.17487/RFC8422, August 2018, 729 . 731 [RFC8465] Atarius, R., Ed., "Using the Mobile Equipment Identity 732 (MEID) URN as an Instance ID", RFC 8465, 733 DOI 10.17487/RFC8465, September 2018, 734 . 736 10.2. Informative References 738 [Bhargavan2016] 739 Bhargavan, K. and G. Leuren, "Transcript Collision 740 Attacks: Breaking Authentication in TLS, IKE, and SSH 741 https://www.mitls.org/downloads/ 742 transcript-collisions.pdf", 2016. 744 [Canada] Treasury Board of Canada Secretariat, "Implementing HTTPS 745 for Secure Web Connections: Information Technology Policy 746 Implementation Notice (ITPIN)", June 2018, 747 . 752 [NIST800-52r2] 753 National Institute of Standards and Technology, "NIST 754 SP800-52r2 https://csrc.nist.gov/CSRC/media/Publications/ 755 sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf", 756 2018. 758 [PCI-TLS1] 759 PCI Security Standards Council, "Migrating from SSL and 760 Early TLS https://www.pcisecuritystandards.org/documents/ 761 Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf", 2016. 763 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 764 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 765 Second and Third Generation Cellular Hosts", RFC 3316, 766 DOI 10.17487/RFC3316, April 2003, 767 . 769 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 770 "STUN - Simple Traversal of User Datagram Protocol (UDP) 771 Through Network Address Translators (NATs)", RFC 3489, 772 DOI 10.17487/RFC3489, March 2003, 773 . 775 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 776 and T. Wright, "Transport Layer Security (TLS) 777 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 778 . 780 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 781 Arkko, "Diameter Base Protocol", RFC 3588, 782 DOI 10.17487/RFC3588, September 2003, 783 . 785 [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 786 Transport Over TCP", RFC 3734, DOI 10.17487/RFC3734, March 787 2004, . 789 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 790 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 791 October 2004, . 793 [RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 794 Cipher Suites to Transport Layer Security (TLS)", 795 RFC 4132, DOI 10.17487/RFC4132, July 2005, 796 . 798 [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation 799 Protocol (SIP) for Request History Information", RFC 4244, 800 DOI 10.17487/RFC4244, November 2005, 801 . 803 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 804 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 805 . 807 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 808 and T. Wright, "Transport Layer Security (TLS) 809 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 810 . 812 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 813 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 814 for Transport Layer Security (TLS)", RFC 4492, 815 DOI 10.17487/RFC4492, May 2006, 816 . 818 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 819 "Transport Layer Security (TLS) Session Resumption without 820 Server-Side State", RFC 4507, DOI 10.17487/RFC4507, May 821 2006, . 823 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 824 Transport Layer Security (TLS) Protocol in the Session 825 Description Protocol (SDP)", RFC 4572, 826 DOI 10.17487/RFC4572, July 2006, 827 . 829 [RFC4934] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 830 Transport Over TCP", RFC 4934, DOI 10.17487/RFC4934, May 831 2007, . 833 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 834 "Transport Layer Security (TLS) Session Resumption without 835 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 836 January 2008, . 838 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 839 Layer Security (TLS) Authentication", RFC 5081, 840 DOI 10.17487/RFC5081, November 2007, 841 . 843 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 844 Export (IPFIX) Protocol for the Exchange of IP Traffic 845 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 846 2008, . 848 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 849 (TLS) Protocol Version 1.2", RFC 5246, 850 DOI 10.17487/RFC5246, August 2008, 851 . 853 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 854 Known Attacks on Transport Layer Security (TLS) and 855 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 856 February 2015, . 858 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 859 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 860 . 862 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 863 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 864 . 866 Appendix A. Change Log 868 [[RFC editor: please remove this before publication.]] 870 From draft-ietf-tls-oldversions-deprecate-00 to draft-ietf-tls- 871 oldversions-deprecate-01: 873 o PRs with typos and similar: so far just #1 874 o PR#2 noting msft browser announced deprecation (but this was OBE 875 as per...) 876 o Implemented actions as per IETF-103 meeting: 878 * Details about which RFC's, BCP's are affected were generated 879 using a script in the git repo: https://github.com/tlswg/ 880 oldversions-deprecate/blob/master/nonobsnorms.sh 881 * Removed the 'measurements' part 882 * Removed SHA-1 deprecation (section 8 of -00) 884 From draft-moriarty-tls-oldversions-diediedie-01 to draft-ietf-tls- 885 oldversions-deprecate-00: 887 o I-Ds became RFCs 8446/8447 (old-repo PR#4, for TLS1.3) 888 o Accepted old-repo PR#5 fixing typos 890 From draft-moriarty-tls-oldversions-diediedie-00 to draft-moriarty- 891 tls-oldversions-diediedie-01: 893 o Added stats sent to list so far 894 o PR's #2,3 895 o a few more references 896 o added section on email 898 Authors' Addresses 900 Kathleen Moriarty 901 Dell EMC 902 176 South Street 903 Hopkinton 904 United States 906 EMail: Kathleen.Moriarty.ietf@gmail.com 907 Stephen Farrell 908 Trinity College Dublin 909 Dublin 2 910 Ireland 912 Phone: +353-1-896-2354 913 EMail: stephen.farrell@cs.tcd.ie