idnits 2.17.1 draft-ietf-tls-oldversions-deprecate-08.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 draft header indicates that this document obsoletes RFC7507, but the abstract doesn't seem to mention this, which it should. -- 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 RFC7525, but the abstract doesn't seem to directly say this. It does mention RFC7525 though, so this could be OK. -- 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2020) is 1290 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: 33 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 Obsoletes: 7507 (if approved) S. Farrell 5 Updates: 8465 8422 8261 7568 7562 7525 Trinity College Dublin 6 7465 7030 6750 6749 6739 6460 October 14, 2020 7 6614 6367 6347 6176 6084 6083 8 6042 6012 5878 5734 5469 5456 9 5422 5415 5364 5281 5263 5238 10 5216 5158 5091 5054 5049 5024 11 5023 5019 5018 4992 4976 4975 12 4964 4851 4823 4791 4785 4744 13 4743 4732 4712 4681 4680 4642 14 4616 4582 4540 4531 4513 4497 15 4279 4261 4235 4217 4168 4162 16 4111 4097 3983 3943 3903 3887 17 3871 3856 3767 3749 3656 3568 18 3552 3501 3470 3436 3329 3261 19 (if approved) 20 Intended status: Best Current Practice 21 Expires: April 17, 2021 23 Deprecating TLSv1.0 and TLSv1.1 24 draft-ietf-tls-oldversions-deprecate-08 26 Abstract 28 This document, if approved, formally deprecates Transport Layer 29 Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). 30 Accordingly, those documents (will be moved|have been moved) to 31 Historic status. These versions lack support for current and 32 recommended cryptographic algorithms and mechanisms, and various 33 government and industry profiles of applications using TLS now 34 mandate avoiding these old TLS versions. TLSv1.2 has been the 35 recommended version for IETF protocols since 2008, providing 36 sufficient time to transition away from older versions. Removing 37 support for older versions from implementations reduces the attack 38 surface, reduces opportunity for misconfiguration, and streamlines 39 library and product maintenance. 41 This document also deprecates Datagram TLS (DTLS) version 1.0 42 (RFC6347), but not DTLS version 1.2, and there is no DTLS version 43 1.1. 45 This document updates many RFCs that normatively refer to TLSv1.0 or 46 TLSv1.1 as described herein. This document also updates the best 47 practices for TLS usage in RFC 7525 and hence is part of BCP195. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on April 17, 2021. 66 Copyright Notice 68 Copyright (c) 2020 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. RFCs Updated . . . . . . . . . . . . . . . . . . . . . . 3 85 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 86 2. Support for Deprecation . . . . . . . . . . . . . . . . . . . 5 87 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 . . . . . . . 6 88 4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6 89 5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 7 90 6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 7 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 96 10.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 104 [RFC4346] were superceded by TLSv1.2 [RFC5246] in 2008, which has now 105 itself been superceded by TLSv1.3 [RFC8446]. Datagram Transport 106 Layer Security (DTLS) version 1.0 [RFC4347] was superceded by 107 DTLSv1.2 [RFC6347] in 2012. It is therefore timely to further 108 deprecate these old versions. 110 Technical reasons for deprecating these versions include: 112 o They require implementation of older cipher suites that are no 113 longer desirable for cryptographic reasons, e.g., TLSv1.0 makes 114 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement 115 o Lack of support for current recommended cipher suites, especially 116 AEAD ciphers which are not supported prior to TLSv1.2. Note: 117 registry entries for no-longer-desirable ciphersuites remain in 118 the registries, but many TLS registries are being updated through 119 [RFC8447] which indicates that such entries are not recommended by 120 the IETF. 121 o Integrity of the handshake depends on SHA-1 hash. 122 o Authentication of the peers depends on SHA-1 signatures. 123 o Support for four TLS protocol versions increases the likelihood of 124 misconfiguration. 125 o At least one widely-used library has plans to drop TLSv1.1 and 126 TLSv1.0 support in upcoming releases; products using such 127 libraries would need to use older versions of the libraries to 128 support TLSv1.0 and TLSv1.1, which is clearly undesirable. 130 Deprecation of these versions is intended to assist developers as 131 additional justification to no longer support older (D)TLS versions 132 and to migrate to a minimum of (D)TLSv1.2. Deprecation also assists 133 product teams with phasing out support for the older versions, to 134 reduce the attack surface and the scope of maintenance for protocols 135 in their offerings. 137 1.1. RFCs Updated 139 This document updates the following RFCs that normatively reference 140 TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of 141 these older versions. Fallback to these versions are prohibited 142 through this update. Specific references to mandatory minimum 143 protocol versions of TLSv1.0 or TLSv1.1 are replaced by TLSv1.2, and 144 references to minimum protocol version DTLSv1.0 are replaced by 145 DTLSv1.2. Statements that "TLS 1.0 is the most widely deployed 146 version and will provide the broadest interoperability" are removed 147 without replacement. 149 [RFC8465] [RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7465] 150 [RFC7030] [RFC6750] [RFC6749] [RFC6739] [RFC6084] [RFC6083] [RFC6367] 151 [RFC6176] [RFC6042] [RFC6012] [RFC5878] [RFC5734] [RFC5469] [RFC5456] 152 [RFC5422] [RFC5415] [RFC5364] [RFC5281] [RFC5263] [RFC5238] [RFC5216] 153 [RFC5158] [RFC5091] [RFC5054] [RFC5049] [RFC5024] [RFC5023] [RFC5019] 154 [RFC5018] [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC4851] [RFC4823] 155 [RFC4791] [RFC4785] [RFC4732] [RFC4712] [RFC4681] [RFC4680] [RFC4642] 156 [RFC4616] [RFC4582] [RFC4540] [RFC4531] [RFC4513] [RFC4497] [RFC4279] 157 [RFC4261] [RFC4235] [RFC4217] [RFC4168] [RFC4162] [RFC4111] [RFC4097] 158 [RFC3983] [RFC3943] [RFC3903] [RFC3887] [RFC3871] [RFC3856] [RFC3767] 159 [RFC3749] [RFC3656] [RFC3568] [RFC3552] [RFC3501] [RFC3470] [RFC3436] 160 [RFC3329] [RFC3261] 162 The status of [RFC7562], [RFC6042], [RFC5456], [RFC5024], [RFC4540], 163 and [RFC3656] will be updated with permission of the Independent 164 Stream Editor. 166 In addition these RFCs normatively refer to TLSv1.0 or TLSv1.1 and 167 have already been obsoleted; they are still listed here and marked as 168 updated by this document in order to reiterate that any usage of the 169 obsolete protocol should still use modern TLS: [RFC7507] [RFC5101] 170 [RFC5081] [RFC5077] [RFC4934] [RFC4572] [RFC4507] [RFC4492] [RFC4366] 171 [RFC4347] [RFC4244] [RFC4132] [RFC3920] [RFC3734] [RFC3588] [RFC3546] 172 [RFC3489] [RFC3316] 174 Note that [RFC4642] has already been updated by [RFC8143], which 175 makes an overlapping, but not quite identical, update as this 176 document. 178 [RFC6614] has a requirement for TLSv1.1 or later, although only makes 179 an informative reference to [RFC4346]. This requirement is updated 180 to be for TLSv1.2 or later. 182 [RFC6460], [RFC4744], and [RFC4743] are already Historic; they are 183 still listed here and marked as updated by this document in order to 184 reiterate that any usage of the obsolete protocol should still use 185 modern TLS. 187 This document updates DTLS [RFC6347]. [RFC6347] had allowed for 188 negotiating the use of DTLSv1.0, which is now forbidden. 190 1.2. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 2. Support for Deprecation 200 Specific details on attacks against TLSv1.0 and TLSv1.1, as well as 201 their mitigations, are provided in [NIST800-52r2], RFC 7457 [RFC7457] 202 and other RFCs referenced therein. Although mitigations for the 203 current known vulnerabilities have been developed, any future issues 204 discovered in old protocol versions might not be mitigated in older 205 library versions when newer library versions do not support those old 206 protocols. 208 NIST for example have provided the following rationale, copied with 209 permission from [NIST800-52r2], section 1.2 "History of TLS" (with 210 references changed for RFC formatting). 212 TLS 1.1, specified in [RFC4346], was developed to address 213 weaknesses discovered in TLS 1.0, primarily in the areas of 214 initialization vector selection and padding error processing. 215 Initialization vectors were made explicit to prevent a certain 216 class of attacks on the Cipher Block Chaining (CBC) mode of 217 operation used by TLS. The handling of padding errors was altered 218 to treat a padding error as a bad message authentication code, 219 rather than a decryption failure. In addition, the TLS 1.1 RFC 220 acknowledges attacks on CBC mode that rely on the time to compute 221 the message authentication code (MAC). The TLS 1.1 specification 222 states that to defend against such attacks, an implementation must 223 process records in the same manner regardless of whether padding 224 errors exist. Further implementation considerations for CBC modes 225 (which were not included in RFC4346 [RFC4346]) are discussed in 226 Section 3.3.2. 228 TLSv1.2, specified in RFC5246 [RFC5246], made several 229 cryptographic enhancements, particularly in the area of hash 230 functions, with the ability to use or specify the SHA-2 family 231 algorithms for hash, MAC, and Pseudorandom Function (PRF) 232 computations. TLSv1.2 also adds authenticated encryption with 233 associated data (AEAD) cipher suites. 235 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant 236 change to TLS that aims to address threats that have arisen over 237 the years. Among the changes are a new handshake protocol, a new 238 key derivation process that uses the HMAC-based Extract-and-Expand 239 Key Derivation Function (HKDF), and the removal of cipher suites 240 that use static RSA or DH key exchanges, the CBC mode of 241 operation, or SHA-1. The list of extensions that can be used with 242 TLS 1.3 has been reduced considerably. 244 3. SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1 246 The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 247 hash of the exchanged messages. This makes it possible to perform a 248 downgrade attack on the handshake by an attacker able to perform 2^77 249 operations, well below the acceptable modern security margin. 251 Similarly, the authentication of the handshake depends on signatures 252 made using a SHA-1 hash or a not appreciably stronger concatenation 253 of MD-5 and SHA-1 hashes, allowing the attacker to impersonate a 254 server when it is able to break the severely weakened SHA-1 hash. 256 Neither TLSv1.0 nor TLSv1.1 allow the peers to select a stronger hash 257 for signatures in the ServerKeyExchange or CertificateVerify 258 messages, making the only upgrade path the use of a newer protocol 259 version. 261 See [Bhargavan2016] for additional detail. 263 4. Do Not Use TLSv1.0 265 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of 266 TLS MUST NOT be permitted. 268 Any other version of TLS is more secure than TLSv1.0. While TLSv1.0 269 can be configured to prevent some types of interception, using the 270 highest version available is preferred. 272 Pragmatically, clients MUST NOT send a ClientHello with 273 ClientHello.client_version set to {03,01}. Similarly, servers MUST 274 NOT send a ServerHello with ServerHello.server_version set to 275 {03,01}. Any party receiving a Hello message with the protocol 276 version set to {03,01} MUST respond with a "protocol_version" alert 277 message and close the connection. 279 Historically, TLS specifications were not clear on what the record 280 layer version number (TLSPlaintext.version) could contain when 281 sending ClientHello. Appendix E of [RFC5246] notes that 282 TLSPlaintext.version could be selected to maximize interoperability, 283 though no definitive value is identified as ideal. That guidance is 284 still applicable; therefore, TLS servers MUST accept any value 285 {03,XX} (including {03,00}) as the record layer version number for 286 ClientHello, but they MUST NOT negotiate TLSv1.0. 288 5. Do Not Use TLSv1.1 290 TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of 291 TLS MUST NOT be permitted. 293 Pragmatically, clients MUST NOT send a ClientHello with 294 ClientHello.client_version set to {03,02}. Similarly, servers MUST 295 NOT send a ServerHello with ServerHello.server_version set to 296 {03,02}. Any party receiving a Hello message with the protocol 297 version set to {03,02} MUST respond with a "protocol_version" alert 298 message and close the connection. 300 Any newer version of TLS is more secure than TLSv1.1. While TLSv1.1 301 can be configured to prevent some types of interception, using the 302 highest version available is preferred. Support for TLSv1.1 is 303 dwindling in libraries and will impact security going forward if 304 mitigations for attacks cannot be easily addressed and supported in 305 older libraries. 307 Historically, TLS specifications were not clear on what the record 308 layer version number (TLSPlaintext.version) could contain when 309 sending ClientHello. Appendix E of [RFC5246] notes that 310 TLSPlaintext.version could be selected to maximize interoperability, 311 though no definitive value is identified as ideal. That guidance is 312 still applicable; therefore, TLS servers MUST accept any value 313 {03,XX} (including {03,00}) as the record layer version number for 314 ClientHello, but they MUST NOT negotiate TLSv1.1. 316 6. Updates to RFC7525 318 RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer 319 Security (TLS) and Datagram Transport Layer Security (DTLS)", which 320 is the most recent best practice document for implementing TLS and 321 was based on TLSv1.2. At the time of publication, TLSv1.0 and 322 TLSv1.1 had not yet been deprecated. As such, this document is 323 called out specifically to update text implementing the deprecation 324 recommendations of this document. 326 This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to 327 MUST NOT as follows: 329 o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 331 Rationale: TLSv1.0 (published in 1999) does not support many 332 modern, strong cipher suites. In addition, TLSv1.0 lacks a per- 333 record Initialization Vector (IV) for CBC-based cipher suites and 334 does not warn against common padding errors. 336 o Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 338 Rationale: TLSv1.1 (published in 2006) is a security improvement 339 over TLSv1.0 but still does not support certain stronger cipher 340 suites. 342 This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to 343 MUST NOT as follows: 345 o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347], 346 [RFC6347]. 348 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 350 7. Security Considerations 352 This document deprecates two older TLS protocol versions and one 353 older DTLS protocol version for security reasons already described. 354 The attack surface is reduced when there are a smaller number of 355 supported protocols and fallback options are removed. 357 8. Acknowledgements 359 Thanks to those that provided usage data, reviewed and/or improved 360 this document, including: David Benjamin, David Black, Alan DeKok, 361 Viktor Dukhovni, Julien Elie, Gary Gapinski, Alessandro Ghedini, 362 Jeremy Harris, James Hodgkinson, Russ Housley, Hubert Kario, Ben 363 Kaduk, John Mattsson, Eric Mill, Yoav Nir, Andrei Popov, Eric 364 Rescorla, Yaron Sheffer, Robert Sparks, Martin Thomson, Loganaden 365 Velvindron, and Jakub Wilk. 367 [[Note to RFC editor: At least Julien Elie's name above should have 368 an accent on the first letter of the surname. Please fix that and 369 any others needing a similar fix if you can, I'm not sure the tooling 370 I have now allows that.]] 372 9. IANA Considerations 374 [[This memo includes no request to IANA.]] 376 10. References 377 10.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 385 RFC 2246, DOI 10.17487/RFC2246, January 1999, 386 . 388 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 389 A., Peterson, J., Sparks, R., Handley, M., and E. 390 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 391 DOI 10.17487/RFC3261, June 2002, 392 . 394 [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 395 Haukka, "Security Mechanism Agreement for the Session 396 Initiation Protocol (SIP)", RFC 3329, 397 DOI 10.17487/RFC3329, January 2003, 398 . 400 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 401 Layer Security over Stream Control Transmission Protocol", 402 RFC 3436, DOI 10.17487/RFC3436, December 2002, 403 . 405 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 406 the Use of Extensible Markup Language (XML) within IETF 407 Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, 408 January 2003, . 410 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 411 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 412 . 414 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 415 Text on Security Considerations", BCP 72, RFC 3552, 416 DOI 10.17487/RFC3552, July 2003, 417 . 419 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 420 Content Network (CN) Request-Routing Mechanisms", 421 RFC 3568, DOI 10.17487/RFC3568, July 2003, 422 . 424 [RFC3656] Siemborski, R., "The Mailbox Update (MUPDATE) Distributed 425 Mailbox Database Protocol", RFC 3656, 426 DOI 10.17487/RFC3656, December 2003, 427 . 429 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 430 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 431 2004, . 433 [RFC3767] Farrell, S., Ed., "Securely Available Credentials 434 Protocol", RFC 3767, DOI 10.17487/RFC3767, June 2004, 435 . 437 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 438 Initiation Protocol (SIP)", RFC 3856, 439 DOI 10.17487/RFC3856, August 2004, 440 . 442 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 443 Large Internet Service Provider (ISP) IP Network 444 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 445 2004, . 447 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 448 DOI 10.17487/RFC3887, September 2004, 449 . 451 [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) 452 Extension for Event State Publication", RFC 3903, 453 DOI 10.17487/RFC3903, October 2004, 454 . 456 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 457 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 458 DOI 10.17487/RFC3943, November 2004, 459 . 461 [RFC3983] Newton, A. and M. Sanz, "Using the Internet Registry 462 Information Service (IRIS) over the Blocks Extensible 463 Exchange Protocol (BEEP)", RFC 3983, DOI 10.17487/RFC3983, 464 January 2005, . 466 [RFC4097] Barnes, M., Ed., "Middlebox Communications (MIDCOM) 467 Protocol Evaluation", RFC 4097, DOI 10.17487/RFC4097, June 468 2005, . 470 [RFC4111] Fang, L., Ed., "Security Framework for Provider- 471 Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 472 DOI 10.17487/RFC4111, July 2005, 473 . 475 [RFC4162] Lee, H., Yoon, J., and J. Lee, "Addition of SEED Cipher 476 Suites to Transport Layer Security (TLS)", RFC 4162, 477 DOI 10.17487/RFC4162, August 2005, 478 . 480 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 481 Stream Control Transmission Protocol (SCTP) as a Transport 482 for the Session Initiation Protocol (SIP)", RFC 4168, 483 DOI 10.17487/RFC4168, October 2005, 484 . 486 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 487 DOI 10.17487/RFC4217, October 2005, 488 . 490 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 491 INVITE-Initiated Dialog Event Package for the Session 492 Initiation Protocol (SIP)", RFC 4235, 493 DOI 10.17487/RFC4235, November 2005, 494 . 496 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 497 Service (COPS) Over Transport Layer Security (TLS)", 498 RFC 4261, DOI 10.17487/RFC4261, December 2005, 499 . 501 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 502 Ciphersuites for Transport Layer Security (TLS)", 503 RFC 4279, DOI 10.17487/RFC4279, December 2005, 504 . 506 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 507 (TLS) Protocol Version 1.1", RFC 4346, 508 DOI 10.17487/RFC4346, April 2006, 509 . 511 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 512 "Interworking between the Session Initiation Protocol 513 (SIP) and QSIG", BCP 117, RFC 4497, DOI 10.17487/RFC4497, 514 May 2006, . 516 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 517 (LDAP): Authentication Methods and Security Mechanisms", 518 RFC 4513, DOI 10.17487/RFC4513, June 2006, 519 . 521 [RFC4531] Zeilenga, K., "Lightweight Directory Access Protocol 522 (LDAP) Turn Operation", RFC 4531, DOI 10.17487/RFC4531, 523 June 2006, . 525 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 526 Middlebox Configuration (SIMCO) Protocol Version 3.0", 527 RFC 4540, DOI 10.17487/RFC4540, May 2006, 528 . 530 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 531 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 532 November 2006, . 534 [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 535 Security Layer (SASL) Mechanism", RFC 4616, 536 DOI 10.17487/RFC4616, August 2006, 537 . 539 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 540 Transport Layer Security (TLS) with Network News Transfer 541 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 542 2006, . 544 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 545 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 546 . 548 [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User 549 Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, 550 October 2006, . 552 [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., 553 and Y. Kim, "Transport Mappings for Real-time Application 554 Quality-of-Service Monitoring (RAQMON) Protocol Data Unit 555 (PDU)", RFC 4712, DOI 10.17487/RFC4712, October 2006, 556 . 558 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 559 Denial-of-Service Considerations", RFC 4732, 560 DOI 10.17487/RFC4732, December 2006, 561 . 563 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 564 Protocol (SOAP)", RFC 4743, DOI 10.17487/RFC4743, December 565 2006, . 567 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 568 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 569 DOI 10.17487/RFC4744, December 2006, 570 . 572 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 573 Ciphersuites with NULL Encryption for Transport Layer 574 Security (TLS)", RFC 4785, DOI 10.17487/RFC4785, January 575 2007, . 577 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 578 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 579 DOI 10.17487/RFC4791, March 2007, 580 . 582 [RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- 583 to-Peer Business Data Interchange over the Internet", 584 RFC 4823, DOI 10.17487/RFC4823, April 2007, 585 . 587 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 588 Flexible Authentication via Secure Tunneling Extensible 589 Authentication Protocol Method (EAP-FAST)", RFC 4851, 590 DOI 10.17487/RFC4851, May 2007, 591 . 593 [RFC4964] Allen, A., Ed., Holm, J., and T. Hallin, "The P-Answer- 594 State Header Extension to the Session Initiation Protocol 595 for the Open Mobile Alliance Push to Talk over Cellular", 596 RFC 4964, DOI 10.17487/RFC4964, September 2007, 597 . 599 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 600 "The Message Session Relay Protocol (MSRP)", RFC 4975, 601 DOI 10.17487/RFC4975, September 2007, 602 . 604 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 605 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 606 DOI 10.17487/RFC4976, September 2007, 607 . 609 [RFC4992] Newton, A., "XML Pipelining with Chunks for the Internet 610 Registry Information Service", RFC 4992, 611 DOI 10.17487/RFC4992, August 2007, 612 . 614 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 615 Floor Control Protocol (BFCP)", RFC 5018, 616 DOI 10.17487/RFC5018, September 2007, 617 . 619 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 620 Certificate Status Protocol (OCSP) Profile for High-Volume 621 Environments", RFC 5019, DOI 10.17487/RFC5019, September 622 2007, . 624 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 625 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 626 October 2007, . 628 [RFC5024] Friend, I., "ODETTE File Transfer Protocol 2.0", RFC 5024, 629 DOI 10.17487/RFC5024, November 2007, 630 . 632 [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, Ed., 633 "Applying Signaling Compression (SigComp) to the Session 634 Initiation Protocol (SIP)", RFC 5049, 635 DOI 10.17487/RFC5049, December 2007, 636 . 638 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 639 "Using the Secure Remote Password (SRP) Protocol for TLS 640 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 641 2007, . 643 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 644 Standard (IBCS) #1: Supersingular Curve Implementations of 645 the BF and BB1 Cryptosystems", RFC 5091, 646 DOI 10.17487/RFC5091, December 2007, 647 . 649 [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", 650 RFC 5158, DOI 10.17487/RFC5158, March 2008, 651 . 653 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 654 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 655 March 2008, . 657 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 658 the Datagram Congestion Control Protocol (DCCP)", 659 RFC 5238, DOI 10.17487/RFC5238, May 2008, 660 . 662 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 663 Khartabil, "Session Initiation Protocol (SIP) Extension 664 for Partial Notification of Presence Information", 665 RFC 5263, DOI 10.17487/RFC5263, September 2008, 666 . 668 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 669 Protocol Tunneled Transport Layer Security Authenticated 670 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 671 DOI 10.17487/RFC5281, August 2008, 672 . 674 [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup 675 Language (XML) Format Extension for Representing Copy 676 Control Attributes in Resource Lists", RFC 5364, 677 DOI 10.17487/RFC5364, October 2008, 678 . 680 [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, 681 "Dynamic Provisioning Using Flexible Authentication via 682 Secure Tunneling Extensible Authentication Protocol (EAP- 683 FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009, 684 . 686 [RFC5469] Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport 687 Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469, 688 February 2009, . 690 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 691 Transport over TCP", STD 69, RFC 5734, 692 DOI 10.17487/RFC5734, August 2009, 693 . 695 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 696 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 697 May 2010, . 699 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 700 Authorization Using KeyNote", RFC 6042, 701 DOI 10.17487/RFC6042, October 2010, 702 . 704 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 705 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 706 2011, . 708 [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher 709 Suites to Transport Layer Security (TLS)", RFC 6367, 710 DOI 10.17487/RFC6367, September 2011, 711 . 713 [RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service 714 Boundaries and Elements Based on the Location- 715 to-Service Translation (LoST) Protocol", RFC 6739, 716 DOI 10.17487/RFC6739, October 2012, 717 . 719 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 720 RFC 6749, DOI 10.17487/RFC6749, October 2012, 721 . 723 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 724 Framework: Bearer Token Usage", RFC 6750, 725 DOI 10.17487/RFC6750, October 2012, 726 . 728 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 729 "Enrollment over Secure Transport", RFC 7030, 730 DOI 10.17487/RFC7030, October 2013, 731 . 733 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 734 DOI 10.17487/RFC7465, February 2015, 735 . 737 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 738 Suite Value (SCSV) for Preventing Protocol Downgrade 739 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 740 . 742 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 743 "Recommendations for Secure Use of Transport Layer 744 Security (TLS) and Datagram Transport Layer Security 745 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 746 2015, . 748 [RFC7562] Thakore, D., "Transport Layer Security (TLS) Authorization 749 Using Digital Transmission Content Protection (DTCP) 750 Certificates", RFC 7562, DOI 10.17487/RFC7562, July 2015, 751 . 753 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 754 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 755 DOI 10.17487/RFC7568, June 2015, 756 . 758 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 759 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 760 May 2017, . 762 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 763 Curve Cryptography (ECC) Cipher Suites for Transport Layer 764 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 765 DOI 10.17487/RFC8422, August 2018, 766 . 768 [RFC8465] Atarius, R., Ed., "Using the Mobile Equipment Identity 769 (MEID) URN as an Instance ID", RFC 8465, 770 DOI 10.17487/RFC8465, September 2018, 771 . 773 10.2. Informative References 775 [Bhargavan2016] 776 Bhargavan, K. and G. Leuren, "Transcript Collision 777 Attacks: Breaking Authentication in TLS, IKE, and SSH 778 https://www.mitls.org/downloads/transcript- 779 collisions.pdf", 2016. 781 [NIST800-52r2] 782 National Institute of Standards and Technology, "NIST 783 SP800-52r2 784 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 785 NIST.SP.800-52r2.pdf", August 2019. 787 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 788 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 789 Second and Third Generation Cellular Hosts", RFC 3316, 790 DOI 10.17487/RFC3316, April 2003, 791 . 793 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 794 "STUN - Simple Traversal of User Datagram Protocol (UDP) 795 Through Network Address Translators (NATs)", RFC 3489, 796 DOI 10.17487/RFC3489, March 2003, 797 . 799 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 800 and T. Wright, "Transport Layer Security (TLS) 801 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 802 . 804 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 805 Arkko, "Diameter Base Protocol", RFC 3588, 806 DOI 10.17487/RFC3588, September 2003, 807 . 809 [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 810 Transport Over TCP", RFC 3734, DOI 10.17487/RFC3734, March 811 2004, . 813 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 814 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 815 October 2004, . 817 [RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 818 Cipher Suites to Transport Layer Security (TLS)", 819 RFC 4132, DOI 10.17487/RFC4132, July 2005, 820 . 822 [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation 823 Protocol (SIP) for Request History Information", RFC 4244, 824 DOI 10.17487/RFC4244, November 2005, 825 . 827 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 828 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 829 . 831 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 832 and T. Wright, "Transport Layer Security (TLS) 833 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 834 . 836 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 837 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 838 for Transport Layer Security (TLS)", RFC 4492, 839 DOI 10.17487/RFC4492, May 2006, 840 . 842 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 843 "Transport Layer Security (TLS) Session Resumption without 844 Server-Side State", RFC 4507, DOI 10.17487/RFC4507, May 845 2006, . 847 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 848 Transport Layer Security (TLS) Protocol in the Session 849 Description Protocol (SDP)", RFC 4572, 850 DOI 10.17487/RFC4572, July 2006, 851 . 853 [RFC4934] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 854 Transport Over TCP", RFC 4934, DOI 10.17487/RFC4934, May 855 2007, . 857 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 858 "Transport Layer Security (TLS) Session Resumption without 859 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 860 January 2008, . 862 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 863 Layer Security (TLS) Authentication", RFC 5081, 864 DOI 10.17487/RFC5081, November 2007, 865 . 867 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 868 Export (IPFIX) Protocol for the Exchange of IP Traffic 869 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 870 2008, . 872 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 873 (TLS) Protocol Version 1.2", RFC 5246, 874 DOI 10.17487/RFC5246, August 2008, 875 . 877 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 878 Ed., "Control And Provisioning of Wireless Access Points 879 (CAPWAP) Protocol Specification", RFC 5415, 880 DOI 10.17487/RFC5415, March 2009, 881 . 883 [RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. 884 Shumard, "IAX: Inter-Asterisk eXchange Version 2", 885 RFC 5456, DOI 10.17487/RFC5456, February 2010, 886 . 888 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 889 "Datagram Transport Layer Security (DTLS) Transport 890 Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012, 891 October 2010, . 893 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 894 Transport Layer Security (DTLS) for Stream Control 895 Transmission Protocol (SCTP)", RFC 6083, 896 DOI 10.17487/RFC6083, January 2011, 897 . 899 [RFC6084] Fu, X., Dickmann, C., and J. Crowcroft, "General Internet 900 Signaling Transport (GIST) over Stream Control 901 Transmission Protocol (SCTP) and Datagram Transport Layer 902 Security (DTLS)", RFC 6084, DOI 10.17487/RFC6084, January 903 2011, . 905 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 906 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 907 January 2012, . 909 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 910 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 911 January 2012, . 913 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 914 "Transport Layer Security (TLS) Encryption for RADIUS", 915 RFC 6614, DOI 10.17487/RFC6614, May 2012, 916 . 918 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 919 Known Attacks on Transport Layer Security (TLS) and 920 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 921 February 2015, . 923 [RFC8143] Elie, J., "Using Transport Layer Security (TLS) with 924 Network News Transfer Protocol (NNTP)", RFC 8143, 925 DOI 10.17487/RFC8143, April 2017, 926 . 928 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, 929 "Datagram Transport Layer Security (DTLS) Encapsulation of 930 SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 931 2017, . 933 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 934 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 935 . 937 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 938 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 939 . 941 Appendix A. Change Log 943 [[RFC editor: please remove this before publication.]] 945 From draft-ietf-tls-oldversions-deprecate-05 to draft-ietf-tls- 946 oldversions-deprecate-06: 948 o Fixed "yaleman" ack. 949 o Added RFC6614 to UPDATEs list. 950 o per preliminary AD review: 952 * Remove references from abstract 953 * s/primary technical reasons/technical reasons/ 954 * Add rfc7030 to 1.1 955 * verified that all the RFCs in the (massive:-) Updates meta-data 956 are mentioned in section 1.1 (I think appropriately;-) 958 From draft-ietf-tls-oldversions-deprecate-04 to draft-ietf-tls- 959 oldversions-deprecate-05: 961 o Removed references to goverment related deprecation statements: 962 US, Canada, and Germany. NIST documentation rationale remains as 963 a reference describing the relevent RFCs and justification. 965 From draft-ietf-tls-oldversions-deprecate-02 to draft-ietf-tls- 966 oldversions-deprecate-03: 968 o Added 8261 to updates list based on IETF-104 meeting. 970 From draft-ietf-tls-oldversions-deprecate-01 to draft-ietf-tls- 971 oldversions-deprecate-02: 973 o Correction: 2nd list of referenced RFCs in Section 1.1 aren't 974 informatively refering to tls1.0/1.1 975 o Remove RFC7255 from updates list - datatracker has bad data 976 (spotted by Robert Sparks) 977 o Added point about RFCs 8143 and 4642 978 o Added UPDATEs for RFCs that refer to 4347 and aren't OBSOLETEd 979 o Added note about RFC8261 to see what WG want. 981 From draft-ietf-tls-oldversions-deprecate-00 to draft-ietf-tls- 982 oldversions-deprecate-01: 984 o PRs with typos and similar: so far just #1 985 o PR#2 noting msft browser announced deprecation (but this was OBE 986 as per...) 987 o Implemented actions as per IETF-103 meeting: 989 * Details about which RFC's, BCP's are affected were generated 990 using a script in the git repo: https://github.com/tlswg/ 991 oldversions-deprecate/blob/master/nonobsnorms.sh 992 * Removed the 'measurements' part 993 * Removed SHA-1 deprecation (section 8 of -00) 995 From draft-moriarty-tls-oldversions-diediedie-01 to draft-ietf-tls- 996 oldversions-deprecate-00: 998 o I-Ds became RFCs 8446/8447 (old-repo PR#4, for TLSv1.3) 999 o Accepted old-repo PR#5 fixing typos 1001 From draft-moriarty-tls-oldversions-diediedie-00 to draft-moriarty- 1002 tls-oldversions-diediedie-01: 1004 o Added stats sent to list so far 1005 o PR's #2,3 1006 o a few more references 1007 o added section on email 1009 Authors' Addresses 1011 Kathleen Moriarty 1012 Dell EMC 1013 176 South Street 1014 Hopkinton 1015 United States 1017 EMail: Kathleen.Moriarty.ietf@gmail.com 1019 Stephen Farrell 1020 Trinity College Dublin 1021 Dublin 2 1022 Ireland 1024 Phone: +353-1-896-2354 1025 EMail: stephen.farrell@cs.tcd.ie