idnits 2.17.1 draft-ietf-tls-oldversions-deprecate-05.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 ([RFC6347], [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 RFC8261, 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2019) is 1770 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 ** 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) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 34 errors (**), 0 flaws (~~), 1 warning (==), 26 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 8261 7568 7562 7525 S. Farrell 5 7507 7465 7030 6750 6749 6739 Trinity College Dublin 6 6460 6084 6083 6367 6347 6176 June 20, 2019 7 6042 6012 5878 5734 5469 5456 8 5422 5415 5364 5281 5263 5238 9 5216 5158 5091 5054 5049 5024 10 5023 5019 5018 4992 4976 4975 11 4964 4851 4823 4791 4785 4744 12 4743 4732 4712 4681 4680 4642 13 4616 4582 4540 4531 4513 4497 14 4279 4261 4235 4217 4168 4162 15 4111 4097 3983 3943 3903 3887 16 3871 3856 3767 3749 3656 3568 17 3552 3501 3470 3436 3329 3261 18 (if approved) 19 Intended status: Best Current Practice 20 Expires: December 22, 2019 22 Deprecating TLSv1.0 and TLSv1.1 23 draft-ietf-tls-oldversions-deprecate-05 25 Abstract 27 This document, if approved, formally deprecates Transport Layer 28 Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves 29 these documents to the historic state. These versions lack support 30 for current and recommended cipher suites, and various government and 31 industry profiles of applications using TLS now mandate avoiding 32 these old TLS versions. TLSv1.2 has been the recommended version for 33 IETF protocols since 2008, providing sufficient time to transition 34 away from older versions. Products having to support older versions 35 increase the attack surface unnecessarily and increase opportunities 36 for misconfigurations. Supporting these older versions also requires 37 additional effort for library and product maintenance. 39 This document also deprecates Datagram TLS (DTLS) version 1.0 40 [RFC6347] (but not DTLS version 1.2, and there is no DTLS version 41 1.1). 43 This document updates many RFCs that normatively refer to TLSv1.0 or 44 TLSv1.1 as described herein. This document also updates RFC 7525 and 45 hence is part of BCP195. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on December 22, 2019. 64 Copyright Notice 66 Copyright (c) 2019 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 1.1. RFCs Updated . . . . . . . . . . . . . . . . . . . . . . 3 83 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 84 2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 4 85 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 . . . . . . . 5 86 4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6 87 5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 6 88 6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 7 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 94 10.2. Informative References . . . . . . . . . . . . . . . . . 16 96 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 99 1. Introduction 101 Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 102 [RFC4346] were superceded by TLSv1.2 [RFC5246] in 2008, which has now 103 itself been superceded by TLSv1.3 [RFC8446]. It is therefore timely 104 to further deprecate these old versions. The expectation is that 105 TLSv1.2 will continue to be used for many years alongside TLSv1.3. 107 The primary technical reasons for deprecating these versions include: 109 o They require implementation of older cipher suites that are no 110 longer desirable for cryptographic reasons, e.g. TLSv1.0 makes 111 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement 112 o Lack of support for current recommended cipher suites, especially 113 using AEAD ciphers which are not supported prior to TLSv1.2. 114 Note: registry entries for no-longer-desirable ciphersuites remain 115 in the registries, but many TLS registries are being updated 116 through [RFC8447] which denotes such entries as "not recommended." 117 o Integrity of the handshake depends on SHA-1 hash 118 o Authentication of the peers depends on SHA-1 signatures 119 o Support for four protocol versions increases the likelihood of 120 misconfiguration 121 o At least one widely-used library has plans to drop TLSv1.1 and 122 TLSv1.0 support in upcoming releases; products using such 123 libraries would need to use older versions of the libraries to 124 support TLSv1.0 and TLSv1.1, which is clearly undesirable 126 Deprecation of these versions is intended to assist developers as 127 additional justification to no longer support older TLS versions and 128 to migrate to a minimum of TLSv1.2. Deprecation also assists product 129 teams with phasing out support for the older versions to reduce the 130 attack surface and the scope of maintenance for protocols in their 131 offerings. 133 1.1. RFCs Updated 135 This document updates the following RFCs that normatively reference 136 TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of 137 these older versions. Fallback to these versions are prohibited 138 through this update. 140 [RFC8465] [RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7507] 141 [RFC7465] [RFC6750] [RFC6749] [RFC6739] [RFC6460] [RFC6084] [RFC6083] 142 [RFC6367] [RFC6176] [RFC6042] [RFC6012] [RFC5878] [RFC5734] [RFC5469] 143 [RFC5456] [RFC5422] [RFC5415] [RFC5364] [RFC5281] [RFC5263] [RFC5238] 145 [RFC5216] [RFC5158] [RFC5091] [RFC5054] [RFC5049] [RFC5024] [RFC5023] 146 [RFC5019] [RFC5018] [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC4851] 147 [RFC4823] [RFC4791] [RFC4785] [RFC4744] [RFC4743] [RFC4732] [RFC4712] 148 [RFC4681] [RFC4680] [RFC4642] [RFC4616] [RFC4582] [RFC4540] [RFC4531] 149 [RFC4513] [RFC4497] [RFC4279] [RFC4261] [RFC4235] [RFC4217] [RFC4168] 150 [RFC4162] [RFC4111] [RFC4097] [RFC3983] [RFC3943] [RFC3903] [RFC3887] 151 [RFC3871] [RFC3856] [RFC3767] [RFC3749] [RFC3656] [RFC3568] [RFC3552] 152 [RFC3501] [RFC3470] [RFC3436] [RFC3329] [RFC3261] 154 In addition these RFCs normatively refer to TLSv1.0 or TLSv1.1 and 155 have been obsoleted: [RFC5101] [RFC5081] [RFC5077] [RFC4934] 156 [RFC4572] [RFC4507] [RFC4492] [RFC4366] [RFC4347] [RFC4244] [RFC4132] 157 [RFC3920] [RFC3734] [RFC3588] [RFC3546] [RFC3489] [RFC3316] 159 In the case of [RFC4642], that has already been updated by [RFC8143] 160 which makes an overlapping, but not quite the same, update as this 161 document. 163 This document updates DTLS [RFC6347]. 165 1.2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 2. Support for Deprecation 175 Specific details on attacks against TLSv1.0 and TLSv1.1 as well as 176 their mitigations are provided in NIST SP800-52r2 [NIST800-52r2], RFC 177 7457 [RFC7457] and other referenced RFCs. Although the attacks have 178 been mitigated, if support is dropped for future library releases for 179 these versions, it is unlikely attacks found going forward will be 180 mitigated in older library releases. 182 NIST for example have provided the following rationale, copied with 183 permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History 184 of TLS" (with references changed for RFC formatting). 186 TLS 1.1, specified in [RFC4346], was developed to address 187 weaknesses discovered in TLS 1.0, primarily in the areas of 188 initialization vector selection and padding error processing. 189 Initialization vectors were made explicit to prevent a certain 190 class of attacks on the Cipher Block Chaining (CBC) mode of 191 operation used by TLS. The handling of padding errors was altered 192 to treat a padding error as a bad message authentication code, 193 rather than a decryption failure. In addition, the TLS 1.1 RFC 194 acknowledges attacks on CBC mode that rely on the time to compute 195 the message authentication code (MAC). The TLS 1.1 specification 196 states that to defend against such attacks, an implementation must 197 process records in the same manner regardless of whether padding 198 errors exist. Further implementation considerations for CBC modes 199 (which were not included in RFC4346 [RFC4346]) are discussed in 200 Section 3.3.2. 202 TLSv1.2, specified in RFC5246 [RFC5246], made several 203 cryptographic enhancements, particularly in the area of hash 204 functions, with the ability to use or specify the SHA-2 family 205 algorithms for hash, MAC, and Pseudorandom Function (PRF) 206 computations. TLSv1.2 also adds authenticated encryption with 207 associated data (AEAD) cipher suites. 209 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant 210 change to TLS that aims to address threats that have arisen over 211 the years. Among the changes are a new handshake protocol, a new 212 key derivation process that uses the HMAC-based Extract-and-Expand 213 Key Derivation Function (HKDF), and the removal of cipher suites 214 that use static RSA or DH key exchanges, the CBC mode of 215 operation, or SHA-1. The list of extensions that can be used with 216 TLS 1.3 has been reduced considerably. 218 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.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 RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer 292 Security (TLS) and Datagram Transport Layer Security (DTLS)", is the 293 most recent best practice document for implementing TLS and was based 294 on TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not 295 yet been deprecated. As such, this document is called out 296 specifically to update text implementing the deprecation 297 recommendations of this document. 299 This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to 300 MUST NOT as follows: 302 o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 304 Rationale: TLSv1.0 (published in 1999) does not support many 305 modern, strong cipher suites. In addition, TLSv1.0 lacks a per- 306 record Initialization Vector (IV) for CBC-based cipher suites and 307 does not warn against common padding errors. 309 o Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 311 Rationale: TLSv1.1 (published in 2006) is a security improvement 312 over TLSv1.0 but still does not support certain stronger cipher 313 suites. 315 This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to 316 MUST NOT as follows: 318 o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347], 319 [RFC6347]. 321 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 323 7. Security Considerations 325 This document deprecates two older protocol versions for security 326 reasons already described. The attack surface is reduced when there 327 are a smaller number of supported protocols and fallback options are 328 removed. 330 8. Acknowledgements 332 Thanks to those that provided usage data, reviewed and/or improved 333 this document, including: David Benjamin, David Black, Viktor 334 Dukhovni, Julien Elie, Gary Gapinski, Alessandro Ghedini, Jeremy 335 Harris, Russ Housley, Hubert Kario, John Mattsson, Eric Mill, Yoav 336 Nir, Andrei Popov, Eric Rescorla, Yaron Sheffer, Robert Sparks, 337 Martin Thomson, Loganaden Velvindron, https://github.com/yaleman, and 338 Jakub Wilk. 340 [[Note to RFC editor: At least Julien Elie's name above should have 341 an accent on the first letter of the surname. Please fix that and 342 any others needing a similar fix if you can, I'm not sure the tooling 343 I have now allows that.]] 345 9. IANA Considerations 347 [[This memo includes no request to IANA.]] 349 10. References 351 10.1. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 359 RFC 2246, DOI 10.17487/RFC2246, January 1999, 360 . 362 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 363 A., Peterson, J., Sparks, R., Handley, M., and E. 364 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 365 DOI 10.17487/RFC3261, June 2002, 366 . 368 [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 369 Haukka, "Security Mechanism Agreement for the Session 370 Initiation Protocol (SIP)", RFC 3329, 371 DOI 10.17487/RFC3329, January 2003, 372 . 374 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 375 Layer Security over Stream Control Transmission Protocol", 376 RFC 3436, DOI 10.17487/RFC3436, December 2002, 377 . 379 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 380 the Use of Extensible Markup Language (XML) within IETF 381 Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, 382 January 2003, . 384 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 385 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 386 . 388 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 389 Text on Security Considerations", BCP 72, RFC 3552, 390 DOI 10.17487/RFC3552, July 2003, 391 . 393 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 394 Content Network (CN) Request-Routing Mechanisms", 395 RFC 3568, DOI 10.17487/RFC3568, July 2003, 396 . 398 [RFC3656] Siemborski, R., "The Mailbox Update (MUPDATE) Distributed 399 Mailbox Database Protocol", RFC 3656, 400 DOI 10.17487/RFC3656, December 2003, 401 . 403 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 404 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 405 2004, . 407 [RFC3767] Farrell, S., Ed., "Securely Available Credentials 408 Protocol", RFC 3767, DOI 10.17487/RFC3767, June 2004, 409 . 411 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 412 Initiation Protocol (SIP)", RFC 3856, 413 DOI 10.17487/RFC3856, August 2004, 414 . 416 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 417 Large Internet Service Provider (ISP) IP Network 418 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 419 2004, . 421 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 422 DOI 10.17487/RFC3887, September 2004, 423 . 425 [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) 426 Extension for Event State Publication", RFC 3903, 427 DOI 10.17487/RFC3903, October 2004, 428 . 430 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 431 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 432 DOI 10.17487/RFC3943, November 2004, 433 . 435 [RFC3983] Newton, A. and M. Sanz, "Using the Internet Registry 436 Information Service (IRIS) over the Blocks Extensible 437 Exchange Protocol (BEEP)", RFC 3983, DOI 10.17487/RFC3983, 438 January 2005, . 440 [RFC4097] Barnes, M., Ed., "Middlebox Communications (MIDCOM) 441 Protocol Evaluation", RFC 4097, DOI 10.17487/RFC4097, June 442 2005, . 444 [RFC4111] Fang, L., Ed., "Security Framework for Provider- 445 Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 446 DOI 10.17487/RFC4111, July 2005, 447 . 449 [RFC4162] Lee, H., Yoon, J., and J. Lee, "Addition of SEED Cipher 450 Suites to Transport Layer Security (TLS)", RFC 4162, 451 DOI 10.17487/RFC4162, August 2005, 452 . 454 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 455 Stream Control Transmission Protocol (SCTP) as a Transport 456 for the Session Initiation Protocol (SIP)", RFC 4168, 457 DOI 10.17487/RFC4168, October 2005, 458 . 460 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 461 DOI 10.17487/RFC4217, October 2005, 462 . 464 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 465 INVITE-Initiated Dialog Event Package for the Session 466 Initiation Protocol (SIP)", RFC 4235, 467 DOI 10.17487/RFC4235, November 2005, 468 . 470 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 471 Service (COPS) Over Transport Layer Security (TLS)", 472 RFC 4261, DOI 10.17487/RFC4261, December 2005, 473 . 475 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 476 Ciphersuites for Transport Layer Security (TLS)", 477 RFC 4279, DOI 10.17487/RFC4279, December 2005, 478 . 480 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 481 (TLS) Protocol Version 1.1", RFC 4346, 482 DOI 10.17487/RFC4346, April 2006, 483 . 485 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 486 "Interworking between the Session Initiation Protocol 487 (SIP) and QSIG", BCP 117, RFC 4497, DOI 10.17487/RFC4497, 488 May 2006, . 490 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 491 (LDAP): Authentication Methods and Security Mechanisms", 492 RFC 4513, DOI 10.17487/RFC4513, June 2006, 493 . 495 [RFC4531] Zeilenga, K., "Lightweight Directory Access Protocol 496 (LDAP) Turn Operation", RFC 4531, DOI 10.17487/RFC4531, 497 June 2006, . 499 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 500 Middlebox Configuration (SIMCO) Protocol Version 3.0", 501 RFC 4540, DOI 10.17487/RFC4540, May 2006, 502 . 504 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 505 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 506 November 2006, . 508 [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 509 Security Layer (SASL) Mechanism", RFC 4616, 510 DOI 10.17487/RFC4616, August 2006, 511 . 513 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 514 Transport Layer Security (TLS) with Network News Transfer 515 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 516 2006, . 518 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 519 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 520 . 522 [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User 523 Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, 524 October 2006, . 526 [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., 527 and Y. Kim, "Transport Mappings for Real-time Application 528 Quality-of-Service Monitoring (RAQMON) Protocol Data Unit 529 (PDU)", RFC 4712, DOI 10.17487/RFC4712, October 2006, 530 . 532 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 533 Denial-of-Service Considerations", RFC 4732, 534 DOI 10.17487/RFC4732, December 2006, 535 . 537 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 538 Protocol (SOAP)", RFC 4743, DOI 10.17487/RFC4743, December 539 2006, . 541 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 542 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 543 DOI 10.17487/RFC4744, December 2006, 544 . 546 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 547 Ciphersuites with NULL Encryption for Transport Layer 548 Security (TLS)", RFC 4785, DOI 10.17487/RFC4785, January 549 2007, . 551 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 552 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 553 DOI 10.17487/RFC4791, March 2007, 554 . 556 [RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- 557 to-Peer Business Data Interchange over the Internet", 558 RFC 4823, DOI 10.17487/RFC4823, April 2007, 559 . 561 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 562 Flexible Authentication via Secure Tunneling Extensible 563 Authentication Protocol Method (EAP-FAST)", RFC 4851, 564 DOI 10.17487/RFC4851, May 2007, 565 . 567 [RFC4964] Allen, A., Ed., Holm, J., and T. Hallin, "The P-Answer- 568 State Header Extension to the Session Initiation Protocol 569 for the Open Mobile Alliance Push to Talk over Cellular", 570 RFC 4964, DOI 10.17487/RFC4964, September 2007, 571 . 573 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 574 "The Message Session Relay Protocol (MSRP)", RFC 4975, 575 DOI 10.17487/RFC4975, September 2007, 576 . 578 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 579 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 580 DOI 10.17487/RFC4976, September 2007, 581 . 583 [RFC4992] Newton, A., "XML Pipelining with Chunks for the Internet 584 Registry Information Service", RFC 4992, 585 DOI 10.17487/RFC4992, August 2007, 586 . 588 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 589 Floor Control Protocol (BFCP)", RFC 5018, 590 DOI 10.17487/RFC5018, September 2007, 591 . 593 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 594 Certificate Status Protocol (OCSP) Profile for High-Volume 595 Environments", RFC 5019, DOI 10.17487/RFC5019, September 596 2007, . 598 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 599 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 600 October 2007, . 602 [RFC5024] Friend, I., "ODETTE File Transfer Protocol 2.0", RFC 5024, 603 DOI 10.17487/RFC5024, November 2007, 604 . 606 [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, Ed., 607 "Applying Signaling Compression (SigComp) to the Session 608 Initiation Protocol (SIP)", RFC 5049, 609 DOI 10.17487/RFC5049, December 2007, 610 . 612 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 613 "Using the Secure Remote Password (SRP) Protocol for TLS 614 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 615 2007, . 617 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 618 Standard (IBCS) #1: Supersingular Curve Implementations of 619 the BF and BB1 Cryptosystems", RFC 5091, 620 DOI 10.17487/RFC5091, December 2007, 621 . 623 [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", 624 RFC 5158, DOI 10.17487/RFC5158, March 2008, 625 . 627 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 628 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 629 March 2008, . 631 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 632 the Datagram Congestion Control Protocol (DCCP)", 633 RFC 5238, DOI 10.17487/RFC5238, May 2008, 634 . 636 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 637 Khartabil, "Session Initiation Protocol (SIP) Extension 638 for Partial Notification of Presence Information", 639 RFC 5263, DOI 10.17487/RFC5263, September 2008, 640 . 642 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 643 Protocol Tunneled Transport Layer Security Authenticated 644 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 645 DOI 10.17487/RFC5281, August 2008, 646 . 648 [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup 649 Language (XML) Format Extension for Representing Copy 650 Control Attributes in Resource Lists", RFC 5364, 651 DOI 10.17487/RFC5364, October 2008, 652 . 654 [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, 655 "Dynamic Provisioning Using Flexible Authentication via 656 Secure Tunneling Extensible Authentication Protocol (EAP- 657 FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009, 658 . 660 [RFC5469] Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport 661 Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469, 662 February 2009, . 664 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 665 Transport over TCP", STD 69, RFC 5734, 666 DOI 10.17487/RFC5734, August 2009, 667 . 669 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 670 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 671 May 2010, . 673 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 674 Authorization Using KeyNote", RFC 6042, 675 DOI 10.17487/RFC6042, October 2010, 676 . 678 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 679 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 680 2011, . 682 [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher 683 Suites to Transport Layer Security (TLS)", RFC 6367, 684 DOI 10.17487/RFC6367, September 2011, 685 . 687 [RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service 688 Boundaries and Elements Based on the Location- 689 to-Service Translation (LoST) Protocol", RFC 6739, 690 DOI 10.17487/RFC6739, October 2012, 691 . 693 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 694 RFC 6749, DOI 10.17487/RFC6749, October 2012, 695 . 697 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 698 Framework: Bearer Token Usage", RFC 6750, 699 DOI 10.17487/RFC6750, October 2012, 700 . 702 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 703 DOI 10.17487/RFC7465, February 2015, 704 . 706 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 707 Suite Value (SCSV) for Preventing Protocol Downgrade 708 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 709 . 711 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 712 "Recommendations for Secure Use of Transport Layer 713 Security (TLS) and Datagram Transport Layer Security 714 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 715 2015, . 717 [RFC7562] Thakore, D., "Transport Layer Security (TLS) Authorization 718 Using Digital Transmission Content Protection (DTCP) 719 Certificates", RFC 7562, DOI 10.17487/RFC7562, July 2015, 720 . 722 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 723 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 724 DOI 10.17487/RFC7568, June 2015, 725 . 727 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 728 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 729 May 2017, . 731 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 732 Curve Cryptography (ECC) Cipher Suites for Transport Layer 733 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 734 DOI 10.17487/RFC8422, August 2018, 735 . 737 [RFC8465] Atarius, R., Ed., "Using the Mobile Equipment Identity 738 (MEID) URN as an Instance ID", RFC 8465, 739 DOI 10.17487/RFC8465, September 2018, 740 . 742 10.2. Informative References 744 [Bhargavan2016] 745 Bhargavan, K. and G. Leuren, "Transcript Collision 746 Attacks: Breaking Authentication in TLS, IKE, and SSH 747 https://www.mitls.org/downloads/ 748 transcript-collisions.pdf", 2016. 750 [NIST800-52r2] 751 National Institute of Standards and Technology, "NIST 752 SP800-52r2 https://csrc.nist.gov/CSRC/media/Publications/ 753 sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf", 754 2018. 756 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 757 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 758 Second and Third Generation Cellular Hosts", RFC 3316, 759 DOI 10.17487/RFC3316, April 2003, 760 . 762 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 763 "STUN - Simple Traversal of User Datagram Protocol (UDP) 764 Through Network Address Translators (NATs)", RFC 3489, 765 DOI 10.17487/RFC3489, March 2003, 766 . 768 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 769 and T. Wright, "Transport Layer Security (TLS) 770 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 771 . 773 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 774 Arkko, "Diameter Base Protocol", RFC 3588, 775 DOI 10.17487/RFC3588, September 2003, 776 . 778 [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 779 Transport Over TCP", RFC 3734, DOI 10.17487/RFC3734, March 780 2004, . 782 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 783 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 784 October 2004, . 786 [RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 787 Cipher Suites to Transport Layer Security (TLS)", 788 RFC 4132, DOI 10.17487/RFC4132, July 2005, 789 . 791 [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation 792 Protocol (SIP) for Request History Information", RFC 4244, 793 DOI 10.17487/RFC4244, November 2005, 794 . 796 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 797 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 798 . 800 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 801 and T. Wright, "Transport Layer Security (TLS) 802 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 803 . 805 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 806 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 807 for Transport Layer Security (TLS)", RFC 4492, 808 DOI 10.17487/RFC4492, May 2006, 809 . 811 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 812 "Transport Layer Security (TLS) Session Resumption without 813 Server-Side State", RFC 4507, DOI 10.17487/RFC4507, May 814 2006, . 816 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 817 Transport Layer Security (TLS) Protocol in the Session 818 Description Protocol (SDP)", RFC 4572, 819 DOI 10.17487/RFC4572, July 2006, 820 . 822 [RFC4934] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 823 Transport Over TCP", RFC 4934, DOI 10.17487/RFC4934, May 824 2007, . 826 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 827 "Transport Layer Security (TLS) Session Resumption without 828 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 829 January 2008, . 831 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 832 Layer Security (TLS) Authentication", RFC 5081, 833 DOI 10.17487/RFC5081, November 2007, 834 . 836 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 837 Export (IPFIX) Protocol for the Exchange of IP Traffic 838 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 839 2008, . 841 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 842 (TLS) Protocol Version 1.2", RFC 5246, 843 DOI 10.17487/RFC5246, August 2008, 844 . 846 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 847 Ed., "Control And Provisioning of Wireless Access Points 848 (CAPWAP) Protocol Specification", RFC 5415, 849 DOI 10.17487/RFC5415, March 2009, 850 . 852 [RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. 853 Shumard, "IAX: Inter-Asterisk eXchange Version 2", 854 RFC 5456, DOI 10.17487/RFC5456, February 2010, 855 . 857 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 858 "Datagram Transport Layer Security (DTLS) Transport 859 Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012, 860 October 2010, . 862 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 863 Transport Layer Security (DTLS) for Stream Control 864 Transmission Protocol (SCTP)", RFC 6083, 865 DOI 10.17487/RFC6083, January 2011, 866 . 868 [RFC6084] Fu, X., Dickmann, C., and J. Crowcroft, "General Internet 869 Signaling Transport (GIST) over Stream Control 870 Transmission Protocol (SCTP) and Datagram Transport Layer 871 Security (DTLS)", RFC 6084, DOI 10.17487/RFC6084, January 872 2011, . 874 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 875 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 876 January 2012, . 878 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 879 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 880 January 2012, . 882 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 883 Known Attacks on Transport Layer Security (TLS) and 884 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 885 February 2015, . 887 [RFC8143] Elie, J., "Using Transport Layer Security (TLS) with 888 Network News Transfer Protocol (NNTP)", RFC 8143, 889 DOI 10.17487/RFC8143, April 2017, 890 . 892 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, 893 "Datagram Transport Layer Security (DTLS) Encapsulation of 894 SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 895 2017, . 897 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 898 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 899 . 901 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 902 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 903 . 905 Appendix A. Change Log 907 [[RFC editor: please remove this before publication.]] 909 From draft-ietf-tls-oldversions-deprecate-04 to draft-ietf-tls- 910 oldversions-deprecate-05: 912 o Removed references to goverment related deprecation statements: 913 US, Canada, and Germany. NIST documentation rationale remains as 914 a reference describing the relevent RFCs and justification. 916 From draft-ietf-tls-oldversions-deprecate-02 to draft-ietf-tls- 917 oldversions-deprecate-03: 919 o Added 8261 to updates list based on IETF-104 meeting. 921 From draft-ietf-tls-oldversions-deprecate-01 to draft-ietf-tls- 922 oldversions-deprecate-02: 924 o Correction: 2nd list of referenced RFCs in Section 1.1 aren't 925 informatively refering to tls1.0/1.1 926 o Remove RFC7255 from updates list - datatracker has bad data 927 (spotted by Robert Sparks) 928 o Added point about RFCs 8143 and 4642 929 o Added UPDATEs for RFCs that refer to 4347 and aren't OBSOLETEd 930 o Added note about RFC8261 to see what WG want. 932 From draft-ietf-tls-oldversions-deprecate-00 to draft-ietf-tls- 933 oldversions-deprecate-01: 935 o PRs with typos and similar: so far just #1 936 o PR#2 noting msft browser announced deprecation (but this was OBE 937 as per...) 938 o Implemented actions as per IETF-103 meeting: 940 * Details about which RFC's, BCP's are affected were generated 941 using a script in the git repo: https://github.com/tlswg/ 942 oldversions-deprecate/blob/master/nonobsnorms.sh 943 * Removed the 'measurements' part 944 * Removed SHA-1 deprecation (section 8 of -00) 946 From draft-moriarty-tls-oldversions-diediedie-01 to draft-ietf-tls- 947 oldversions-deprecate-00: 949 o I-Ds became RFCs 8446/8447 (old-repo PR#4, for TLSv1.3) 950 o Accepted old-repo PR#5 fixing typos 951 From draft-moriarty-tls-oldversions-diediedie-00 to draft-moriarty- 952 tls-oldversions-diediedie-01: 954 o Added stats sent to list so far 955 o PR's #2,3 956 o a few more references 957 o added section on email 959 Authors' Addresses 961 Kathleen Moriarty 962 Dell EMC 963 176 South Street 964 Hopkinton 965 United States 967 EMail: Kathleen.Moriarty.ietf@gmail.com 969 Stephen Farrell 970 Trinity College Dublin 971 Dublin 2 972 Ireland 974 Phone: +353-1-896-2354 975 EMail: stephen.farrell@cs.tcd.ie