idnits 2.17.1 draft-ietf-tls-oldversions-deprecate-04.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 (May 10, 2019) is 1806 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) == Unused Reference: 'Canada' is defined on line 762, but no explicit reference was found in the text ** 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 (~~), 2 warnings (==), 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 May 10, 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: November 11, 2019 22 Deprecating TLSv1.0 and TLSv1.1 23 draft-ietf-tls-oldversions-deprecate-04 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 November 11, 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 . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 8 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 TLSv1.1 and TLSv1.0 are also actively being deprecated in accordance 108 with guidance from government agencies (e.g. NIST SP 80052r2 109 [NIST800-52r2]) and industry consortia such as the Payment Card 110 Industry Association (PCI) [PCI-TLS1]. 112 3GPP have deprecated TLSv1.0 and DTLSv1.0 since their release-14 in 113 2016. [TGPP33310] 115 The primary technical reasons for deprecating these versions include: 117 o They require implementation of older cipher suites that are no 118 longer desirable for cryptographic reasons, e.g. TLSv1.0 makes 119 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement 120 o Lack of support for current recommended cipher suites, especially 121 using AEAD ciphers which are not supported prior to TLSv1.2. 122 Note: registry entries for no-longer-desirable ciphersuites remain 123 in the registries, but many TLS registries are being updated 124 through [RFC8447] which denotes such entries as "not recommended." 125 o Integrity of the handshake depends on SHA-1 hash 126 o Authentication of the peers depends on SHA-1 signatures 127 o Support for four protocol versions increases the likelihood of 128 misconfiguration 129 o At least one widely-used library has plans to drop TLSv1.1 and 130 TLSv1.0 support in upcoming releases; products using such 131 libraries would need to use older versions of the libraries to 132 support TLSv1.0 and TLSv1.1, which is clearly undesirable 134 Deprecation of these versions is intended to assist developers as 135 additional justification to no longer support older TLS versions and 136 to migrate to a minimum of TLSv1.2. Deprecation also assists product 137 teams with phasing out support for the older versions to reduce the 138 attack surface and the scope of maintenance for protocols in their 139 offerings. 141 1.1. RFCs Updated 143 This document updates the following RFCs that normatively reference 144 TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of 145 these older versions. Fallback to these versions are prohibited 146 through this update. 148 [RFC8465] [RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7507] 149 [RFC7465] [RFC6750] [RFC6749] [RFC6739] [RFC6460] [RFC6084] [RFC6083] 150 [RFC6367] [RFC6176] [RFC6042] [RFC6012] [RFC5878] [RFC5734] [RFC5469] 151 [RFC5456] [RFC5422] [RFC5415] [RFC5364] [RFC5281] [RFC5263] [RFC5238] 152 [RFC5216] [RFC5158] [RFC5091] [RFC5054] [RFC5049] [RFC5024] [RFC5023] 153 [RFC5019] [RFC5018] [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC4851] 154 [RFC4823] [RFC4791] [RFC4785] [RFC4744] [RFC4743] [RFC4732] [RFC4712] 155 [RFC4681] [RFC4680] [RFC4642] [RFC4616] [RFC4582] [RFC4540] [RFC4531] 156 [RFC4513] [RFC4497] [RFC4279] [RFC4261] [RFC4235] [RFC4217] [RFC4168] 157 [RFC4162] [RFC4111] [RFC4097] [RFC3983] [RFC3943] [RFC3903] [RFC3887] 158 [RFC3871] [RFC3856] [RFC3767] [RFC3749] [RFC3656] [RFC3568] [RFC3552] 159 [RFC3501] [RFC3470] [RFC3436] [RFC3329] [RFC3261] 161 In addition these RFCs normatively refer to TLSv1.0 or TLSv1.1 and 162 have been obsoleted: [RFC5101] [RFC5081] [RFC5077] [RFC4934] 163 [RFC4572] [RFC4507] [RFC4492] [RFC4366] [RFC4347] [RFC4244] [RFC4132] 164 [RFC3920] [RFC3734] [RFC3588] [RFC3546] [RFC3489] [RFC3316] 166 In the case of [RFC4642], that has already been updated by [RFC8143] 167 which makes an overlapping, but not quite the same, update as this 168 document. 170 This document updates DTLS [RFC6347]. 172 1.2. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 2. Support for Deprecation 182 Specific details on attacks against TLSv1.0 and TLSv1.1 as well as 183 their mitigations are provided in NIST SP800-52r2 [NIST800-52r2], RFC 184 7457 [RFC7457] and other referenced RFCs. Although the attacks have 185 been mitigated, if support is dropped for future library releases for 186 these versions, it is unlikely attacks found going forward will be 187 mitigated in older library releases. 189 NIST for example have provided the following rationale, copied with 190 permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History 191 of TLS" (with references changed for RFC formatting). 193 TLS 1.1, specified in [RFC4346], was developed to address 194 weaknesses discovered in TLS 1.0, primarily in the areas of 195 initialization vector selection and padding error processing. 196 Initialization vectors were made explicit to prevent a certain 197 class of attacks on the Cipher Block Chaining (CBC) mode of 198 operation used by TLS. The handling of padding errors was altered 199 to treat a padding error as a bad message authentication code, 200 rather than a decryption failure. In addition, the TLS 1.1 RFC 201 acknowledges attacks on CBC mode that rely on the time to compute 202 the message authentication code (MAC). The TLS 1.1 specification 203 states that to defend against such attacks, an implementation must 204 process records in the same manner regardless of whether padding 205 errors exist. Further implementation considerations for CBC modes 206 (which were not included in RFC4346 [RFC4346]) are discussed in 207 Section 3.3.2. 209 TLSv1.2, specified in RFC5246 [RFC5246], made several 210 cryptographic enhancements, particularly in the area of hash 211 functions, with the ability to use or specify the SHA-2 family 212 algorithms for hash, MAC, and Pseudorandom Function (PRF) 213 computations. TLSv1.2 also adds authenticated encryption with 214 associated data (AEAD) cipher suites. 216 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant 217 change to TLS that aims to address threats that have arisen over 218 the years. Among the changes are a new handshake protocol, a new 219 key derivation process that uses the HMAC-based Extract-and-Expand 220 Key Derivation Function (HKDF), and the removal of cipher suites 221 that use static RSA or DH key exchanges, the CBC mode of 222 operation, or SHA-1. The list of extensions that can be used with 223 TLS 1.3 has been reduced considerably. 225 The German Federal Office for Information Security, recommends 226 against use of TLS versions less than 1.2 in the publication 227 Cryptographic Mechanisms: Recommendations and Key Lengths 228 [TR-02102-2]. 230 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 232 The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 233 hash of the exchanged messages. This makes it possible to perform a 234 downgrade attack on the handshake by an attacker able to perform 2^77 235 operations, well below the acceptable modern security margin. 237 Similarly, the authentication of the handshake depends on signatures 238 made using SHA-1 hash or a not stronger concatenation of MD-5 and 239 SHA-1 hashes, allowing the attacker to impersonate a server when it 240 is able to break the severely weakened SHA-1 hash. 242 Neither TLSv1.0 nor TLSv1.1 allow the peers to select a stronger hash 243 for signatures in the ServerKeyExchange or CertificateVerify 244 messages, making the only upgrade path the use of a newer protocol 245 version. 247 See [Bhargavan2016] for additional detail. 249 4. Do Not Use TLSv1.0 251 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of 252 TLS MUST NOT be permitted. 254 Any other version of TLS is more secure than TLSv1.0. TLSv1.0 can be 255 configured to prevent interception, though using the highest version 256 available is preferable. 258 Pragmatically, clients MUST NOT send a ClientHello with 259 ClientHello.client_version set to {03,01}. Similarly, servers MUST 260 NOT send a ServerHello with ServerHello.server_version set to 261 {03,01}. Any party receiving a Hello message with the protocol 262 version set to {03,01} MUST respond with a "protocol_version" alert 263 message and close the connection. 265 Historically, TLS specifications were not clear on what the record 266 layer version number (TLSPlaintext.version) could contain when 267 sending ClientHello. Appendix E of [RFC5246] notes that 268 TLSPlaintext.version could be selected to maximize interoperability, 269 though no definitive value is identified as ideal. That guidance is 270 still applicable; therefore, TLS servers MUST accept any value 271 {03,XX} (including {03,00}) as the record layer version number for 272 ClientHello, but they MUST NOT negotiate TLSv1.0. 274 5. Do Not Use TLSv1.1 276 TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of 277 TLS MUST NOT be permitted. 279 Pragmatically, clients MUST NOT send a ClientHello with 280 ClientHello.client_version set to {03,02}. Similarly, servers MUST 281 NOT send a ServerHello with ServerHello.server_version set to 282 {03,02}. Any party receiving a Hello message with the protocol 283 version set to {03,02} MUST respond with a "protocol_version" alert 284 message and close the connection. 286 Any newer version of TLS is more secure than TLSv1.1. TLSv1.1 can be 287 configured to prevent interception, though using the highest version 288 available is preferable. Support for TLSv1.1 is dwindling in 289 libraries and will impact security going forward if mitigations for 290 attacks cannot be easily addressed and supported in older libraries. 292 Historically, TLS specifications were not clear on what the record 293 layer version number (TLSPlaintext.version) could contain when 294 sending ClientHello. Appendix E of [RFC5246] notes that 295 TLSPlaintext.version could be selected to maximize interoperability, 296 though no definitive value is identified as ideal. That guidance is 297 still applicable; therefore, TLS servers MUST accept any value 298 {03,XX} (including {03,00}) as the record layer version number for 299 ClientHello, but they MUST NOT negotiate TLSv1.1. 301 6. Updates to RFC7525 303 RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer 304 Security (TLS) and Datagram Transport Layer Security (DTLS)", is the 305 most recent best practice document for implementing TLS and was based 306 on TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not 307 yet been deprecated. As such, this document is called out 308 specifically to update text implementing the deprecation 309 recommendations of this document. 311 This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to 312 MUST NOT as follows: 314 o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 316 Rationale: TLSv1.0 (published in 1999) does not support many 317 modern, strong cipher suites. In addition, TLSv1.0 lacks a per- 318 record Initialization Vector (IV) for CBC-based cipher suites and 319 does not warn against common padding errors. 321 o Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 323 Rationale: TLSv1.1 (published in 2006) is a security improvement 324 over TLSv1.0 but still does not support certain stronger cipher 325 suites. 327 This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to 328 MUST NOT as follows: 330 o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347], 331 [RFC6347]. 333 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 335 7. Security Considerations 337 This document deprecates two older protocol versions for security 338 reasons already described. The attack surface is reduced when there 339 are a smaller number of supported protocols and fallback options are 340 removed. 342 8. Acknowledgements 344 Thanks to those that provided usage data, reviewed and/or improved 345 this document, including: David Benjamin, David Black, Viktor 346 Dukhovni, Julien Elie, Gary Gapinski, Alessandro Ghedini, Jeremy 347 Harris, Russ Housley, Hubert Kario, John Mattsson, Eric Mill, Yoav 348 Nir, Andrei Popov, Eric Rescorla, Yaron Sheffer, Robert Sparks, 349 Martin Thomson, Loganaden Velvindron, https://github.com/yaleman, and 350 Jakub Wilk. 352 [[Note to RFC editor: At least Julien Elie's name above should have 353 an accent on the first letter of the surname. Please fix that and 354 any others needing a similar fix if you can, I'm not sure the tooling 355 I have now allows that.]] 357 9. IANA Considerations 359 [[This memo includes no request to IANA.]] 361 10. References 363 10.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 371 RFC 2246, DOI 10.17487/RFC2246, January 1999, 372 . 374 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 375 A., Peterson, J., Sparks, R., Handley, M., and E. 376 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 377 DOI 10.17487/RFC3261, June 2002, 378 . 380 [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 381 Haukka, "Security Mechanism Agreement for the Session 382 Initiation Protocol (SIP)", RFC 3329, 383 DOI 10.17487/RFC3329, January 2003, 384 . 386 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 387 Layer Security over Stream Control Transmission Protocol", 388 RFC 3436, DOI 10.17487/RFC3436, December 2002, 389 . 391 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 392 the Use of Extensible Markup Language (XML) within IETF 393 Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, 394 January 2003, . 396 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 397 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 398 . 400 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 401 Text on Security Considerations", BCP 72, RFC 3552, 402 DOI 10.17487/RFC3552, July 2003, 403 . 405 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 406 Content Network (CN) Request-Routing Mechanisms", 407 RFC 3568, DOI 10.17487/RFC3568, July 2003, 408 . 410 [RFC3656] Siemborski, R., "The Mailbox Update (MUPDATE) Distributed 411 Mailbox Database Protocol", RFC 3656, 412 DOI 10.17487/RFC3656, December 2003, 413 . 415 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 416 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 417 2004, . 419 [RFC3767] Farrell, S., Ed., "Securely Available Credentials 420 Protocol", RFC 3767, DOI 10.17487/RFC3767, June 2004, 421 . 423 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 424 Initiation Protocol (SIP)", RFC 3856, 425 DOI 10.17487/RFC3856, August 2004, 426 . 428 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 429 Large Internet Service Provider (ISP) IP Network 430 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 431 2004, . 433 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 434 DOI 10.17487/RFC3887, September 2004, 435 . 437 [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) 438 Extension for Event State Publication", RFC 3903, 439 DOI 10.17487/RFC3903, October 2004, 440 . 442 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 443 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 444 DOI 10.17487/RFC3943, November 2004, 445 . 447 [RFC3983] Newton, A. and M. Sanz, "Using the Internet Registry 448 Information Service (IRIS) over the Blocks Extensible 449 Exchange Protocol (BEEP)", RFC 3983, DOI 10.17487/RFC3983, 450 January 2005, . 452 [RFC4097] Barnes, M., Ed., "Middlebox Communications (MIDCOM) 453 Protocol Evaluation", RFC 4097, DOI 10.17487/RFC4097, June 454 2005, . 456 [RFC4111] Fang, L., Ed., "Security Framework for Provider- 457 Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 458 DOI 10.17487/RFC4111, July 2005, 459 . 461 [RFC4162] Lee, H., Yoon, J., and J. Lee, "Addition of SEED Cipher 462 Suites to Transport Layer Security (TLS)", RFC 4162, 463 DOI 10.17487/RFC4162, August 2005, 464 . 466 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 467 Stream Control Transmission Protocol (SCTP) as a Transport 468 for the Session Initiation Protocol (SIP)", RFC 4168, 469 DOI 10.17487/RFC4168, October 2005, 470 . 472 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 473 DOI 10.17487/RFC4217, October 2005, 474 . 476 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 477 INVITE-Initiated Dialog Event Package for the Session 478 Initiation Protocol (SIP)", RFC 4235, 479 DOI 10.17487/RFC4235, November 2005, 480 . 482 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 483 Service (COPS) Over Transport Layer Security (TLS)", 484 RFC 4261, DOI 10.17487/RFC4261, December 2005, 485 . 487 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 488 Ciphersuites for Transport Layer Security (TLS)", 489 RFC 4279, DOI 10.17487/RFC4279, December 2005, 490 . 492 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 493 (TLS) Protocol Version 1.1", RFC 4346, 494 DOI 10.17487/RFC4346, April 2006, 495 . 497 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 498 "Interworking between the Session Initiation Protocol 499 (SIP) and QSIG", BCP 117, RFC 4497, DOI 10.17487/RFC4497, 500 May 2006, . 502 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 503 (LDAP): Authentication Methods and Security Mechanisms", 504 RFC 4513, DOI 10.17487/RFC4513, June 2006, 505 . 507 [RFC4531] Zeilenga, K., "Lightweight Directory Access Protocol 508 (LDAP) Turn Operation", RFC 4531, DOI 10.17487/RFC4531, 509 June 2006, . 511 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 512 Middlebox Configuration (SIMCO) Protocol Version 3.0", 513 RFC 4540, DOI 10.17487/RFC4540, May 2006, 514 . 516 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 517 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 518 November 2006, . 520 [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 521 Security Layer (SASL) Mechanism", RFC 4616, 522 DOI 10.17487/RFC4616, August 2006, 523 . 525 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 526 Transport Layer Security (TLS) with Network News Transfer 527 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 528 2006, . 530 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 531 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 532 . 534 [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User 535 Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, 536 October 2006, . 538 [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., 539 and Y. Kim, "Transport Mappings for Real-time Application 540 Quality-of-Service Monitoring (RAQMON) Protocol Data Unit 541 (PDU)", RFC 4712, DOI 10.17487/RFC4712, October 2006, 542 . 544 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 545 Denial-of-Service Considerations", RFC 4732, 546 DOI 10.17487/RFC4732, December 2006, 547 . 549 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 550 Protocol (SOAP)", RFC 4743, DOI 10.17487/RFC4743, December 551 2006, . 553 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 554 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 555 DOI 10.17487/RFC4744, December 2006, 556 . 558 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 559 Ciphersuites with NULL Encryption for Transport Layer 560 Security (TLS)", RFC 4785, DOI 10.17487/RFC4785, January 561 2007, . 563 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 564 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 565 DOI 10.17487/RFC4791, March 2007, 566 . 568 [RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- 569 to-Peer Business Data Interchange over the Internet", 570 RFC 4823, DOI 10.17487/RFC4823, April 2007, 571 . 573 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 574 Flexible Authentication via Secure Tunneling Extensible 575 Authentication Protocol Method (EAP-FAST)", RFC 4851, 576 DOI 10.17487/RFC4851, May 2007, 577 . 579 [RFC4964] Allen, A., Ed., Holm, J., and T. Hallin, "The P-Answer- 580 State Header Extension to the Session Initiation Protocol 581 for the Open Mobile Alliance Push to Talk over Cellular", 582 RFC 4964, DOI 10.17487/RFC4964, September 2007, 583 . 585 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 586 "The Message Session Relay Protocol (MSRP)", RFC 4975, 587 DOI 10.17487/RFC4975, September 2007, 588 . 590 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 591 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 592 DOI 10.17487/RFC4976, September 2007, 593 . 595 [RFC4992] Newton, A., "XML Pipelining with Chunks for the Internet 596 Registry Information Service", RFC 4992, 597 DOI 10.17487/RFC4992, August 2007, 598 . 600 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 601 Floor Control Protocol (BFCP)", RFC 5018, 602 DOI 10.17487/RFC5018, September 2007, 603 . 605 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 606 Certificate Status Protocol (OCSP) Profile for High-Volume 607 Environments", RFC 5019, DOI 10.17487/RFC5019, September 608 2007, . 610 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 611 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 612 October 2007, . 614 [RFC5024] Friend, I., "ODETTE File Transfer Protocol 2.0", RFC 5024, 615 DOI 10.17487/RFC5024, November 2007, 616 . 618 [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, Ed., 619 "Applying Signaling Compression (SigComp) to the Session 620 Initiation Protocol (SIP)", RFC 5049, 621 DOI 10.17487/RFC5049, December 2007, 622 . 624 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 625 "Using the Secure Remote Password (SRP) Protocol for TLS 626 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 627 2007, . 629 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 630 Standard (IBCS) #1: Supersingular Curve Implementations of 631 the BF and BB1 Cryptosystems", RFC 5091, 632 DOI 10.17487/RFC5091, December 2007, 633 . 635 [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", 636 RFC 5158, DOI 10.17487/RFC5158, March 2008, 637 . 639 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 640 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 641 March 2008, . 643 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 644 the Datagram Congestion Control Protocol (DCCP)", 645 RFC 5238, DOI 10.17487/RFC5238, May 2008, 646 . 648 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 649 Khartabil, "Session Initiation Protocol (SIP) Extension 650 for Partial Notification of Presence Information", 651 RFC 5263, DOI 10.17487/RFC5263, September 2008, 652 . 654 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 655 Protocol Tunneled Transport Layer Security Authenticated 656 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 657 DOI 10.17487/RFC5281, August 2008, 658 . 660 [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup 661 Language (XML) Format Extension for Representing Copy 662 Control Attributes in Resource Lists", RFC 5364, 663 DOI 10.17487/RFC5364, October 2008, 664 . 666 [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, 667 "Dynamic Provisioning Using Flexible Authentication via 668 Secure Tunneling Extensible Authentication Protocol (EAP- 669 FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009, 670 . 672 [RFC5469] Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport 673 Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469, 674 February 2009, . 676 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 677 Transport over TCP", STD 69, RFC 5734, 678 DOI 10.17487/RFC5734, August 2009, 679 . 681 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 682 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 683 May 2010, . 685 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 686 Authorization Using KeyNote", RFC 6042, 687 DOI 10.17487/RFC6042, October 2010, 688 . 690 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 691 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 692 2011, . 694 [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher 695 Suites to Transport Layer Security (TLS)", RFC 6367, 696 DOI 10.17487/RFC6367, September 2011, 697 . 699 [RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service 700 Boundaries and Elements Based on the Location- 701 to-Service Translation (LoST) Protocol", RFC 6739, 702 DOI 10.17487/RFC6739, October 2012, 703 . 705 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 706 RFC 6749, DOI 10.17487/RFC6749, October 2012, 707 . 709 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 710 Framework: Bearer Token Usage", RFC 6750, 711 DOI 10.17487/RFC6750, October 2012, 712 . 714 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 715 DOI 10.17487/RFC7465, February 2015, 716 . 718 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 719 Suite Value (SCSV) for Preventing Protocol Downgrade 720 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 721 . 723 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 724 "Recommendations for Secure Use of Transport Layer 725 Security (TLS) and Datagram Transport Layer Security 726 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 727 2015, . 729 [RFC7562] Thakore, D., "Transport Layer Security (TLS) Authorization 730 Using Digital Transmission Content Protection (DTCP) 731 Certificates", RFC 7562, DOI 10.17487/RFC7562, July 2015, 732 . 734 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 735 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 736 DOI 10.17487/RFC7568, June 2015, 737 . 739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 741 May 2017, . 743 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 744 Curve Cryptography (ECC) Cipher Suites for Transport Layer 745 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 746 DOI 10.17487/RFC8422, August 2018, 747 . 749 [RFC8465] Atarius, R., Ed., "Using the Mobile Equipment Identity 750 (MEID) URN as an Instance ID", RFC 8465, 751 DOI 10.17487/RFC8465, September 2018, 752 . 754 10.2. Informative References 756 [Bhargavan2016] 757 Bhargavan, K. and G. Leuren, "Transcript Collision 758 Attacks: Breaking Authentication in TLS, IKE, and SSH 759 https://www.mitls.org/downloads/ 760 transcript-collisions.pdf", 2016. 762 [Canada] Treasury Board of Canada Secretariat, "Implementing HTTPS 763 for Secure Web Connections: Information Technology Policy 764 Implementation Notice (ITPIN)", June 2018, 765 . 770 [NIST800-52r2] 771 National Institute of Standards and Technology, "NIST 772 SP800-52r2 https://csrc.nist.gov/CSRC/media/Publications/ 773 sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf", 774 2018. 776 [PCI-TLS1] 777 PCI Security Standards Council, "Migrating from SSL and 778 Early TLS https://www.pcisecuritystandards.org/documents/ 779 Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf", 2016. 781 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 782 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 783 Second and Third Generation Cellular Hosts", RFC 3316, 784 DOI 10.17487/RFC3316, April 2003, 785 . 787 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 788 "STUN - Simple Traversal of User Datagram Protocol (UDP) 789 Through Network Address Translators (NATs)", RFC 3489, 790 DOI 10.17487/RFC3489, March 2003, 791 . 793 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 794 and T. Wright, "Transport Layer Security (TLS) 795 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 796 . 798 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 799 Arkko, "Diameter Base Protocol", RFC 3588, 800 DOI 10.17487/RFC3588, September 2003, 801 . 803 [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 804 Transport Over TCP", RFC 3734, DOI 10.17487/RFC3734, March 805 2004, . 807 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 808 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 809 October 2004, . 811 [RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 812 Cipher Suites to Transport Layer Security (TLS)", 813 RFC 4132, DOI 10.17487/RFC4132, July 2005, 814 . 816 [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation 817 Protocol (SIP) for Request History Information", RFC 4244, 818 DOI 10.17487/RFC4244, November 2005, 819 . 821 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 822 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 823 . 825 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 826 and T. Wright, "Transport Layer Security (TLS) 827 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 828 . 830 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 831 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 832 for Transport Layer Security (TLS)", RFC 4492, 833 DOI 10.17487/RFC4492, May 2006, 834 . 836 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 837 "Transport Layer Security (TLS) Session Resumption without 838 Server-Side State", RFC 4507, DOI 10.17487/RFC4507, May 839 2006, . 841 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 842 Transport Layer Security (TLS) Protocol in the Session 843 Description Protocol (SDP)", RFC 4572, 844 DOI 10.17487/RFC4572, July 2006, 845 . 847 [RFC4934] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 848 Transport Over TCP", RFC 4934, DOI 10.17487/RFC4934, May 849 2007, . 851 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 852 "Transport Layer Security (TLS) Session Resumption without 853 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 854 January 2008, . 856 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 857 Layer Security (TLS) Authentication", RFC 5081, 858 DOI 10.17487/RFC5081, November 2007, 859 . 861 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 862 Export (IPFIX) Protocol for the Exchange of IP Traffic 863 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 864 2008, . 866 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 867 (TLS) Protocol Version 1.2", RFC 5246, 868 DOI 10.17487/RFC5246, August 2008, 869 . 871 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 872 Ed., "Control And Provisioning of Wireless Access Points 873 (CAPWAP) Protocol Specification", RFC 5415, 874 DOI 10.17487/RFC5415, March 2009, 875 . 877 [RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. 878 Shumard, "IAX: Inter-Asterisk eXchange Version 2", 879 RFC 5456, DOI 10.17487/RFC5456, February 2010, 880 . 882 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 883 "Datagram Transport Layer Security (DTLS) Transport 884 Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012, 885 October 2010, . 887 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 888 Transport Layer Security (DTLS) for Stream Control 889 Transmission Protocol (SCTP)", RFC 6083, 890 DOI 10.17487/RFC6083, January 2011, 891 . 893 [RFC6084] Fu, X., Dickmann, C., and J. Crowcroft, "General Internet 894 Signaling Transport (GIST) over Stream Control 895 Transmission Protocol (SCTP) and Datagram Transport Layer 896 Security (DTLS)", RFC 6084, DOI 10.17487/RFC6084, January 897 2011, . 899 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 900 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 901 January 2012, . 903 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 904 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 905 January 2012, . 907 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 908 Known Attacks on Transport Layer Security (TLS) and 909 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 910 February 2015, . 912 [RFC8143] Elie, J., "Using Transport Layer Security (TLS) with 913 Network News Transfer Protocol (NNTP)", RFC 8143, 914 DOI 10.17487/RFC8143, April 2017, 915 . 917 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, 918 "Datagram Transport Layer Security (DTLS) Encapsulation of 919 SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 920 2017, . 922 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 923 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 924 . 926 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 927 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 928 . 930 [TGPP33310] 931 3GPP, "TS 33.310 - Network Domain Security (NDS); 932 Authentication Framework (AF)", 2016. 934 [TR-02102-2] 935 The German Federal Office for Information Security https:/ 936 /www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/ 937 TechGuidelines/TG02102/BSI-TR-02102-2.pdf, "Technical 938 Guideline TR-02102-2 Cryptographic Mechanisms: 939 Recommendations and Key Lengths", 2019. 941 Appendix A. Change Log 943 [[RFC editor: please remove this before publication.]] 945 From draft-ietf-tls-oldversions-deprecate-02 to draft-ietf-tls- 946 oldversions-deprecate-03: 948 o Added 8261 to updates list based on IETF-104 meeting. 950 From draft-ietf-tls-oldversions-deprecate-01 to draft-ietf-tls- 951 oldversions-deprecate-02: 953 o Correction: 2nd list of referenced RFCs in Section 1.1 aren't 954 informatively refering to tls1.0/1.1 955 o Remove RFC7255 from updates list - datatracker has bad data 956 (spotted by Robert Sparks) 957 o Added point about RFCs 8143 and 4642 958 o Added UPDATEs for RFCs that refer to 4347 and aren't OBSOLETEd 959 o Added note about RFC8261 to see what WG want. 961 From draft-ietf-tls-oldversions-deprecate-00 to draft-ietf-tls- 962 oldversions-deprecate-01: 964 o PRs with typos and similar: so far just #1 965 o PR#2 noting msft browser announced deprecation (but this was OBE 966 as per...) 967 o Implemented actions as per IETF-103 meeting: 969 * Details about which RFC's, BCP's are affected were generated 970 using a script in the git repo: https://github.com/tlswg/ 971 oldversions-deprecate/blob/master/nonobsnorms.sh 972 * Removed the 'measurements' part 973 * Removed SHA-1 deprecation (section 8 of -00) 975 From draft-moriarty-tls-oldversions-diediedie-01 to draft-ietf-tls- 976 oldversions-deprecate-00: 978 o I-Ds became RFCs 8446/8447 (old-repo PR#4, for TLSv1.3) 979 o Accepted old-repo PR#5 fixing typos 981 From draft-moriarty-tls-oldversions-diediedie-00 to draft-moriarty- 982 tls-oldversions-diediedie-01: 984 o Added stats sent to list so far 985 o PR's #2,3 986 o a few more references 987 o added section on email 989 Authors' Addresses 991 Kathleen Moriarty 992 Dell EMC 993 176 South Street 994 Hopkinton 995 United States 997 EMail: Kathleen.Moriarty.ietf@gmail.com 999 Stephen Farrell 1000 Trinity College Dublin 1001 Dublin 2 1002 Ireland 1004 Phone: +353-1-896-2354 1005 EMail: stephen.farrell@cs.tcd.ie