idnits 2.17.1 draft-ietf-tls-oldversions-deprecate-03.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 (March 26, 2019) is 1858 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Downref: Normative reference to an Informational RFC: RFC 3568 ** Downref: Normative reference to an Experimental RFC: RFC 3656 ** Downref: Normative reference to an Informational RFC: RFC 3871 ** Downref: Normative reference to an Informational RFC: RFC 3943 ** Downref: Normative reference to an Informational RFC: RFC 4097 ** Downref: Normative reference to an Informational RFC: RFC 4111 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Downref: Normative reference to an Experimental RFC: RFC 4531 ** Downref: Normative reference to an Experimental RFC: RFC 4540 ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Downref: Normative reference to an Informational RFC: RFC 4732 ** Downref: Normative reference to an Historic RFC: RFC 4743 ** Downref: Normative reference to an Historic RFC: RFC 4744 ** Downref: Normative reference to an Informational RFC: RFC 4823 ** Downref: Normative reference to an Informational RFC: RFC 4851 ** Downref: Normative reference to an Informational RFC: RFC 4964 ** Downref: Normative reference to an Informational RFC: RFC 5024 ** Downref: Normative reference to an Informational RFC: RFC 5054 ** Downref: Normative reference to an Informational RFC: RFC 5091 ** Downref: Normative reference to an Informational RFC: RFC 5158 ** Downref: Normative reference to an Informational RFC: RFC 5281 ** Downref: Normative reference to an Informational RFC: RFC 5422 ** Obsolete normative reference: RFC 5469 (Obsoleted by RFC 8996) ** Downref: Normative reference to an Experimental RFC: RFC 5878 ** Downref: Normative reference to an Informational RFC: RFC 6042 ** Downref: Normative reference to an Informational RFC: RFC 6367 ** Downref: Normative reference to an Experimental RFC: RFC 6739 ** Obsolete normative reference: RFC 7507 (Obsoleted by RFC 8996) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 7562 ** Downref: Normative reference to an Informational RFC: RFC 8465 -- Obsolete informational reference (is this intentional?): RFC 3316 (Obsoleted by RFC 7066) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3734 (Obsoleted by RFC 4934) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 4132 (Obsoleted by RFC 5932) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 4507 (Obsoleted by RFC 5077) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 4934 (Obsoleted by RFC 5734) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 34 errors (**), 0 flaws (~~), 1 warning (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Moriarty 3 Internet-Draft Dell EMC 4 Updates: 8465 8422 8261 7568 7562 7525 S. Farrell 5 7507 7465 7030 6750 6749 6739 Trinity College Dublin 6 6460 6084 6083 6367 6347 6176 March 26, 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: September 27, 2019 22 Deprecating TLSv1.0 and TLSv1.1 23 draft-ietf-tls-oldversions-deprecate-03 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 September 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 4. Do Not Use TLSv1.0 . . . . . . . . . . . . . . . . . . . . . 6 87 5. Do Not Use TLSv1.1 . . . . . . . . . . . . . . . . . . . . . 6 88 6. Updates to RFC7525 . . . . . . . . . . . . . . . . . . . . . 7 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 94 10.2. Informative References . . . . . . . . . . . . . . . . . 16 96 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 99 1. Introduction 101 Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 102 [RFC4346] were superceded by TLSv1.2 [RFC5246] in 2008, which has now 103 itself been superceded by TLSv1.3 [RFC8446]. It is therefore timely 104 to further deprecate these old versions. The expectation is that 105 TLSv1.2 will continue to be used for many years alongside TLSv1.3. 107 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 these RFCs that normatively reference TLSv1.0 144 or TLSv1.1 or DTLS1.0 and have not been obsoleted: [RFC8465] 145 [RFC8422] [RFC8261] [RFC7568] [RFC7562] [RFC7525] [RFC7507] [RFC7465] 146 [RFC6750] [RFC6749] [RFC6739] [RFC6460] [RFC6084] [RFC6083] [RFC6367] 147 [RFC6176] [RFC6042] [RFC6012] [RFC5878] [RFC5734] [RFC5469] [RFC5456] 148 [RFC5422] [RFC5415] [RFC5364] [RFC5281] [RFC5263] [RFC5238] [RFC5216] 149 [RFC5158] [RFC5091] [RFC5054] [RFC5049] [RFC5024] [RFC5023] [RFC5019] 150 [RFC5018] [RFC4992] [RFC4976] [RFC4975] [RFC4964] [RFC4851] [RFC4823] 151 [RFC4791] [RFC4785] [RFC4744] [RFC4743] [RFC4732] [RFC4712] [RFC4681] 152 [RFC4680] [RFC4642] [RFC4616] [RFC4582] [RFC4540] [RFC4531] [RFC4513] 153 [RFC4497] [RFC4279] [RFC4261] [RFC4235] [RFC4217] [RFC4168] [RFC4162] 154 [RFC4111] [RFC4097] [RFC3983] [RFC3943] [RFC3903] [RFC3887] [RFC3871] 155 [RFC3856] [RFC3767] [RFC3749] [RFC3656] [RFC3568] [RFC3552] [RFC3501] 156 [RFC3470] [RFC3436] [RFC3329] [RFC3261] 158 In addition these RFCs normatively refer to TLSv1.0 or TLSv1.1 and 159 have been obsoleted: [RFC5101] [RFC5081] [RFC5077] [RFC4934] 160 [RFC4572] [RFC4507] [RFC4492] [RFC4366] [RFC4347] [RFC4244] [RFC4132] 161 [RFC3920] [RFC3734] [RFC3588] [RFC3546] [RFC3489] [RFC3316] 163 In the case of [RFC4642], that has already been updated by [RFC8143] 164 which makes an overlapping, but not quite the same, update as this 165 document. 167 This document updates DTLS [RFC6347]. 169 1.2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 2. Support for Deprecation 179 Industry has actively followed guidance provided by NIST and the PCI 180 Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 181 should remain a minimum baseline for TLS support at this time. 183 Specific details on attacks against TLSv1.0 and TLSv1.1 as well as 184 their mitigations are provided in NIST SP800-52r2 [NIST800-52r2], RFC 185 7457 [RFC7457] and other referenced RFCs. Although the attacks have 186 been mitigated, if support is dropped for future library releases for 187 these versions, it is unlikely attacks found going forward will be 188 mitigated in older library releases. 190 NIST for example have provided the following rationale, copied with 191 permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History 192 of TLS" (with references changed for RFC formatting). 194 TLS 1.1, specified in [RFC4346], was developed to address 195 weaknesses discovered in TLS 1.0, primarily in the areas of 196 initialization vector selection and padding error processing. 197 Initialization vectors were made explicit to prevent a certain 198 class of attacks on the Cipher Block Chaining (CBC) mode of 199 operation used by TLS. The handling of padding errors was altered 200 to treat a padding error as a bad message authentication code, 201 rather than a decryption failure. In addition, the TLS 1.1 RFC 202 acknowledges attacks on CBC mode that rely on the time to compute 203 the message authentication code (MAC). The TLS 1.1 specification 204 states that to defend against such attacks, an implementation must 205 process records in the same manner regardless of whether padding 206 errors exist. Further implementation considerations for CBC modes 207 (which were not included in RFC4346 [RFC4346]) are discussed in 208 Section 3.3.2. 210 TLSv1.2, specified in RFC5246 [RFC5246], made several 211 cryptographic enhancements, particularly in the area of hash 212 functions, with the ability to use or specify the SHA-2 family 213 algorithms for hash, MAC, and Pseudorandom Function (PRF) 214 computations. TLSv1.2 also adds authenticated encryption with 215 associated data (AEAD) cipher suites. 217 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant 218 change to TLS that aims to address threats that have arisen over 219 the years. Among the changes are a new handshake protocol, a new 220 key derivation process that uses the HMAC-based Extract-and-Expand 221 Key Derivation Function (HKDF), and the removal of cipher suites 222 that use static RSA or DH key exchanges, the CBC mode of 223 operation, or SHA-1. The list of extensions that can be used with 224 TLS 1.3 has been reduced considerably. 226 The Canadian government treasury board have also mandated that these 227 old versions of TLS not be used. [Canada] 229 Various companies and web sites have announced plans to deprecate 230 these old versions of TLS. 232 3. SHA-1 234 The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 235 hash of the exchanged messages. This makes it possible to perform a 236 downgrade attack on the handshake by an attacker able to perform 2^77 237 operations, well below the acceptable modern security margin. 239 Similarly, the authentication of the handshake depends on signatures 240 made using SHA-1 hash or a not stronger concatenation of MD-5 and 241 SHA-1 hashes, allowing the attacker to impersonate a server when it 242 is able to break the severely weakened SHA-1 hash. 244 Neither TLSv1.0 nor TLSv1.1 allow the peers to select a stronger hash 245 for signatures in the ServerKeyExchange or CertificateVerify 246 messages, making the only upgrade path the use of a newer protocol 247 version. 249 See [Bhargavan2016] for additional detail. 251 4. Do Not Use TLSv1.0 253 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of 254 TLS MUST NOT be permitted. 256 Any other version of TLS is more secure than TLSv1.0. TLSv1.0 can be 257 configured to prevent interception, though using the highest version 258 available is preferable. 260 Pragmatically, clients MUST NOT send a ClientHello with 261 ClientHello.client_version set to {03,01}. Similarly, servers MUST 262 NOT send a ServerHello with ServerHello.server_version set to 263 {03,01}. Any party receiving a Hello message with the protocol 264 version set to {03,01} MUST respond with a "protocol_version" alert 265 message and close the connection. 267 Historically, TLS specifications were not clear on what the record 268 layer version number (TLSPlaintext.version) could contain when 269 sending ClientHello. Appendix E of [RFC5246] notes that 270 TLSPlaintext.version could be selected to maximize interoperability, 271 though no definitive value is identified as ideal. That guidance is 272 still applicable; therefore, TLS servers MUST accept any value 273 {03,XX} (including {03,00}) as the record layer version number for 274 ClientHello, but they MUST NOT negotiate TLSv1.0. 276 5. Do Not Use TLSv1.1 278 TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of 279 TLS MUST NOT be permitted. 281 Pragmatically, clients MUST NOT send a ClientHello with 282 ClientHello.client_version set to {03,02}. Similarly, servers MUST 283 NOT send a ServerHello with ServerHello.server_version set to 284 {03,02}. Any party receiving a Hello message with the protocol 285 version set to {03,02} MUST respond with a "protocol_version" alert 286 message and close the connection. 288 Any newer version of TLS is more secure than TLSv1.1. TLSv1.1 can be 289 configured to prevent interception, though using the highest version 290 available is preferable. Support for TLSv1.1 is dwindling in 291 libraries and will impact security going forward if mitigations for 292 attacks cannot be easily addressed and supported in older libraries. 294 Historically, TLS specifications were not clear on what the record 295 layer version number (TLSPlaintext.version) could contain when 296 sending ClientHello. Appendix E of [RFC5246] notes that 297 TLSPlaintext.version could be selected to maximize interoperability, 298 though no definitive value is identified as ideal. That guidance is 299 still applicable; therefore, TLS servers MUST accept any value 300 {03,XX} (including {03,00}) as the record layer version number for 301 ClientHello, but they MUST NOT negotiate TLSv1.1. 303 6. Updates to RFC7525 305 This documents updates [RFC7525] Section 3.1.1 changing SHOULD NOT to 306 MUST NOT as follows: 308 o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 310 Rationale: TLSv1.0 (published in 1999) does not support many 311 modern, strong cipher suites. In addition, TLSv1.0 lacks a per- 312 record Initialization Vector (IV) for CBC-based cipher suites and 313 does not warn against common padding errors. 315 o Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 317 Rationale: TLSv1.1 (published in 2006) is a security improvement 318 over TLSv1.0 but still does not support certain stronger cipher 319 suites. 321 This documents updates [RFC7525] Section 3.1.2 changing SHOULD NOT to 322 MUST NOT as follows: 324 o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347], 325 [RFC6347]. 327 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 329 7. Security Considerations 331 This document deprecates two older protocol versions for security 332 reasons already described. The attack surface is reduced when there 333 are a smaller number of supported protocols and fallback options are 334 removed. 336 8. Acknowledgements 338 Thanks to those that provided usage data, reviewed and/or improved 339 this document, including: David Benjamin, David Black, Viktor 340 Dukhovni, Julien Elie, Alessandro Ghedini, Jeremy Harris, Russ 341 Housley, Hubert Kario, John Mattsson, Eric Mill, Yoav Nir, Andrei 342 Popov, Eric Rescorla, Yaron Sheffer, Robert Sparks, Loganaden 343 Velvindron, https://github.com/yaleman, and Jakub Wilk. 345 [[Note to RFC editor: At least Julien Elie's name above should have 346 an accent on the first letter of the surname. Please fix that and 347 any others needing a similar fix if you can, I'm not sure the tooling 348 I have now allows that.]] 350 9. IANA Considerations 352 [[This memo includes no request to IANA.]] 354 10. References 356 10.1. Normative References 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 364 RFC 2246, DOI 10.17487/RFC2246, January 1999, 365 . 367 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 368 A., Peterson, J., Sparks, R., Handley, M., and E. 369 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 370 DOI 10.17487/RFC3261, June 2002, 371 . 373 [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 374 Haukka, "Security Mechanism Agreement for the Session 375 Initiation Protocol (SIP)", RFC 3329, 376 DOI 10.17487/RFC3329, January 2003, 377 . 379 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 380 Layer Security over Stream Control Transmission Protocol", 381 RFC 3436, DOI 10.17487/RFC3436, December 2002, 382 . 384 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 385 the Use of Extensible Markup Language (XML) within IETF 386 Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, 387 January 2003, . 389 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 390 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 391 . 393 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 394 Text on Security Considerations", BCP 72, RFC 3552, 395 DOI 10.17487/RFC3552, July 2003, 396 . 398 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 399 Content Network (CN) Request-Routing Mechanisms", 400 RFC 3568, DOI 10.17487/RFC3568, July 2003, 401 . 403 [RFC3656] Siemborski, R., "The Mailbox Update (MUPDATE) Distributed 404 Mailbox Database Protocol", RFC 3656, 405 DOI 10.17487/RFC3656, December 2003, 406 . 408 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 409 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 410 2004, . 412 [RFC3767] Farrell, S., Ed., "Securely Available Credentials 413 Protocol", RFC 3767, DOI 10.17487/RFC3767, June 2004, 414 . 416 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 417 Initiation Protocol (SIP)", RFC 3856, 418 DOI 10.17487/RFC3856, August 2004, 419 . 421 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 422 Large Internet Service Provider (ISP) IP Network 423 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 424 2004, . 426 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 427 DOI 10.17487/RFC3887, September 2004, 428 . 430 [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) 431 Extension for Event State Publication", RFC 3903, 432 DOI 10.17487/RFC3903, October 2004, 433 . 435 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 436 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 437 DOI 10.17487/RFC3943, November 2004, 438 . 440 [RFC3983] Newton, A. and M. Sanz, "Using the Internet Registry 441 Information Service (IRIS) over the Blocks Extensible 442 Exchange Protocol (BEEP)", RFC 3983, DOI 10.17487/RFC3983, 443 January 2005, . 445 [RFC4097] Barnes, M., Ed., "Middlebox Communications (MIDCOM) 446 Protocol Evaluation", RFC 4097, DOI 10.17487/RFC4097, June 447 2005, . 449 [RFC4111] Fang, L., Ed., "Security Framework for Provider- 450 Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 451 DOI 10.17487/RFC4111, July 2005, 452 . 454 [RFC4162] Lee, H., Yoon, J., and J. Lee, "Addition of SEED Cipher 455 Suites to Transport Layer Security (TLS)", RFC 4162, 456 DOI 10.17487/RFC4162, August 2005, 457 . 459 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 460 Stream Control Transmission Protocol (SCTP) as a Transport 461 for the Session Initiation Protocol (SIP)", RFC 4168, 462 DOI 10.17487/RFC4168, October 2005, 463 . 465 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 466 DOI 10.17487/RFC4217, October 2005, 467 . 469 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 470 INVITE-Initiated Dialog Event Package for the Session 471 Initiation Protocol (SIP)", RFC 4235, 472 DOI 10.17487/RFC4235, November 2005, 473 . 475 [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy 476 Service (COPS) Over Transport Layer Security (TLS)", 477 RFC 4261, DOI 10.17487/RFC4261, December 2005, 478 . 480 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 481 Ciphersuites for Transport Layer Security (TLS)", 482 RFC 4279, DOI 10.17487/RFC4279, December 2005, 483 . 485 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 486 (TLS) Protocol Version 1.1", RFC 4346, 487 DOI 10.17487/RFC4346, April 2006, 488 . 490 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 491 "Interworking between the Session Initiation Protocol 492 (SIP) and QSIG", BCP 117, RFC 4497, DOI 10.17487/RFC4497, 493 May 2006, . 495 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 496 (LDAP): Authentication Methods and Security Mechanisms", 497 RFC 4513, DOI 10.17487/RFC4513, June 2006, 498 . 500 [RFC4531] Zeilenga, K., "Lightweight Directory Access Protocol 501 (LDAP) Turn Operation", RFC 4531, DOI 10.17487/RFC4531, 502 June 2006, . 504 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 505 Middlebox Configuration (SIMCO) Protocol Version 3.0", 506 RFC 4540, DOI 10.17487/RFC4540, May 2006, 507 . 509 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 510 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 511 November 2006, . 513 [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 514 Security Layer (SASL) Mechanism", RFC 4616, 515 DOI 10.17487/RFC4616, August 2006, 516 . 518 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 519 Transport Layer Security (TLS) with Network News Transfer 520 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 521 2006, . 523 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 524 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 525 . 527 [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User 528 Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, 529 October 2006, . 531 [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., 532 and Y. Kim, "Transport Mappings for Real-time Application 533 Quality-of-Service Monitoring (RAQMON) Protocol Data Unit 534 (PDU)", RFC 4712, DOI 10.17487/RFC4712, October 2006, 535 . 537 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 538 Denial-of-Service Considerations", RFC 4732, 539 DOI 10.17487/RFC4732, December 2006, 540 . 542 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 543 Protocol (SOAP)", RFC 4743, DOI 10.17487/RFC4743, December 544 2006, . 546 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 547 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 548 DOI 10.17487/RFC4744, December 2006, 549 . 551 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 552 Ciphersuites with NULL Encryption for Transport Layer 553 Security (TLS)", RFC 4785, DOI 10.17487/RFC4785, January 554 2007, . 556 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 557 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 558 DOI 10.17487/RFC4791, March 2007, 559 . 561 [RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- 562 to-Peer Business Data Interchange over the Internet", 563 RFC 4823, DOI 10.17487/RFC4823, April 2007, 564 . 566 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 567 Flexible Authentication via Secure Tunneling Extensible 568 Authentication Protocol Method (EAP-FAST)", RFC 4851, 569 DOI 10.17487/RFC4851, May 2007, 570 . 572 [RFC4964] Allen, A., Ed., Holm, J., and T. Hallin, "The P-Answer- 573 State Header Extension to the Session Initiation Protocol 574 for the Open Mobile Alliance Push to Talk over Cellular", 575 RFC 4964, DOI 10.17487/RFC4964, September 2007, 576 . 578 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 579 "The Message Session Relay Protocol (MSRP)", RFC 4975, 580 DOI 10.17487/RFC4975, September 2007, 581 . 583 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 584 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 585 DOI 10.17487/RFC4976, September 2007, 586 . 588 [RFC4992] Newton, A., "XML Pipelining with Chunks for the Internet 589 Registry Information Service", RFC 4992, 590 DOI 10.17487/RFC4992, August 2007, 591 . 593 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 594 Floor Control Protocol (BFCP)", RFC 5018, 595 DOI 10.17487/RFC5018, September 2007, 596 . 598 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 599 Certificate Status Protocol (OCSP) Profile for High-Volume 600 Environments", RFC 5019, DOI 10.17487/RFC5019, September 601 2007, . 603 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 604 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 605 October 2007, . 607 [RFC5024] Friend, I., "ODETTE File Transfer Protocol 2.0", RFC 5024, 608 DOI 10.17487/RFC5024, November 2007, 609 . 611 [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, Ed., 612 "Applying Signaling Compression (SigComp) to the Session 613 Initiation Protocol (SIP)", RFC 5049, 614 DOI 10.17487/RFC5049, December 2007, 615 . 617 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 618 "Using the Secure Remote Password (SRP) Protocol for TLS 619 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 620 2007, . 622 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 623 Standard (IBCS) #1: Supersingular Curve Implementations of 624 the BF and BB1 Cryptosystems", RFC 5091, 625 DOI 10.17487/RFC5091, December 2007, 626 . 628 [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", 629 RFC 5158, DOI 10.17487/RFC5158, March 2008, 630 . 632 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 633 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 634 March 2008, . 636 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 637 the Datagram Congestion Control Protocol (DCCP)", 638 RFC 5238, DOI 10.17487/RFC5238, May 2008, 639 . 641 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 642 Khartabil, "Session Initiation Protocol (SIP) Extension 643 for Partial Notification of Presence Information", 644 RFC 5263, DOI 10.17487/RFC5263, September 2008, 645 . 647 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 648 Protocol Tunneled Transport Layer Security Authenticated 649 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 650 DOI 10.17487/RFC5281, August 2008, 651 . 653 [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup 654 Language (XML) Format Extension for Representing Copy 655 Control Attributes in Resource Lists", RFC 5364, 656 DOI 10.17487/RFC5364, October 2008, 657 . 659 [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, 660 "Dynamic Provisioning Using Flexible Authentication via 661 Secure Tunneling Extensible Authentication Protocol (EAP- 662 FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009, 663 . 665 [RFC5469] Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport 666 Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469, 667 February 2009, . 669 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 670 Transport over TCP", STD 69, RFC 5734, 671 DOI 10.17487/RFC5734, August 2009, 672 . 674 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 675 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 676 May 2010, . 678 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 679 Authorization Using KeyNote", RFC 6042, 680 DOI 10.17487/RFC6042, October 2010, 681 . 683 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 684 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 685 2011, . 687 [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher 688 Suites to Transport Layer Security (TLS)", RFC 6367, 689 DOI 10.17487/RFC6367, September 2011, 690 . 692 [RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service 693 Boundaries and Elements Based on the Location- 694 to-Service Translation (LoST) Protocol", RFC 6739, 695 DOI 10.17487/RFC6739, October 2012, 696 . 698 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 699 RFC 6749, DOI 10.17487/RFC6749, October 2012, 700 . 702 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 703 Framework: Bearer Token Usage", RFC 6750, 704 DOI 10.17487/RFC6750, October 2012, 705 . 707 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 708 DOI 10.17487/RFC7465, February 2015, 709 . 711 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 712 Suite Value (SCSV) for Preventing Protocol Downgrade 713 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 714 . 716 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 717 "Recommendations for Secure Use of Transport Layer 718 Security (TLS) and Datagram Transport Layer Security 719 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 720 2015, . 722 [RFC7562] Thakore, D., "Transport Layer Security (TLS) Authorization 723 Using Digital Transmission Content Protection (DTCP) 724 Certificates", RFC 7562, DOI 10.17487/RFC7562, July 2015, 725 . 727 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 728 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 729 DOI 10.17487/RFC7568, June 2015, 730 . 732 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 733 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 734 May 2017, . 736 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 737 Curve Cryptography (ECC) Cipher Suites for Transport Layer 738 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 739 DOI 10.17487/RFC8422, August 2018, 740 . 742 [RFC8465] Atarius, R., Ed., "Using the Mobile Equipment Identity 743 (MEID) URN as an Instance ID", RFC 8465, 744 DOI 10.17487/RFC8465, September 2018, 745 . 747 10.2. Informative References 749 [Bhargavan2016] 750 Bhargavan, K. and G. Leuren, "Transcript Collision 751 Attacks: Breaking Authentication in TLS, IKE, and SSH 752 https://www.mitls.org/downloads/ 753 transcript-collisions.pdf", 2016. 755 [Canada] Treasury Board of Canada Secretariat, "Implementing HTTPS 756 for Secure Web Connections: Information Technology Policy 757 Implementation Notice (ITPIN)", June 2018, 758 . 763 [NIST800-52r2] 764 National Institute of Standards and Technology, "NIST 765 SP800-52r2 https://csrc.nist.gov/CSRC/media/Publications/ 766 sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf", 767 2018. 769 [PCI-TLS1] 770 PCI Security Standards Council, "Migrating from SSL and 771 Early TLS https://www.pcisecuritystandards.org/documents/ 772 Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf", 2016. 774 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 775 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 776 Second and Third Generation Cellular Hosts", RFC 3316, 777 DOI 10.17487/RFC3316, April 2003, 778 . 780 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 781 "STUN - Simple Traversal of User Datagram Protocol (UDP) 782 Through Network Address Translators (NATs)", RFC 3489, 783 DOI 10.17487/RFC3489, March 2003, 784 . 786 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 787 and T. Wright, "Transport Layer Security (TLS) 788 Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, 789 . 791 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 792 Arkko, "Diameter Base Protocol", RFC 3588, 793 DOI 10.17487/RFC3588, September 2003, 794 . 796 [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 797 Transport Over TCP", RFC 3734, DOI 10.17487/RFC3734, March 798 2004, . 800 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 801 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 802 October 2004, . 804 [RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 805 Cipher Suites to Transport Layer Security (TLS)", 806 RFC 4132, DOI 10.17487/RFC4132, July 2005, 807 . 809 [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation 810 Protocol (SIP) for Request History Information", RFC 4244, 811 DOI 10.17487/RFC4244, November 2005, 812 . 814 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 815 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 816 . 818 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 819 and T. Wright, "Transport Layer Security (TLS) 820 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 821 . 823 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 824 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 825 for Transport Layer Security (TLS)", RFC 4492, 826 DOI 10.17487/RFC4492, May 2006, 827 . 829 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 830 "Transport Layer Security (TLS) Session Resumption without 831 Server-Side State", RFC 4507, DOI 10.17487/RFC4507, May 832 2006, . 834 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 835 Transport Layer Security (TLS) Protocol in the Session 836 Description Protocol (SDP)", RFC 4572, 837 DOI 10.17487/RFC4572, July 2006, 838 . 840 [RFC4934] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 841 Transport Over TCP", RFC 4934, DOI 10.17487/RFC4934, May 842 2007, . 844 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 845 "Transport Layer Security (TLS) Session Resumption without 846 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 847 January 2008, . 849 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 850 Layer Security (TLS) Authentication", RFC 5081, 851 DOI 10.17487/RFC5081, November 2007, 852 . 854 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 855 Export (IPFIX) Protocol for the Exchange of IP Traffic 856 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 857 2008, . 859 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 860 (TLS) Protocol Version 1.2", RFC 5246, 861 DOI 10.17487/RFC5246, August 2008, 862 . 864 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 865 Ed., "Control And Provisioning of Wireless Access Points 866 (CAPWAP) Protocol Specification", RFC 5415, 867 DOI 10.17487/RFC5415, March 2009, 868 . 870 [RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. 871 Shumard, "IAX: Inter-Asterisk eXchange Version 2", 872 RFC 5456, DOI 10.17487/RFC5456, February 2010, 873 . 875 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 876 "Datagram Transport Layer Security (DTLS) Transport 877 Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012, 878 October 2010, . 880 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 881 Transport Layer Security (DTLS) for Stream Control 882 Transmission Protocol (SCTP)", RFC 6083, 883 DOI 10.17487/RFC6083, January 2011, 884 . 886 [RFC6084] Fu, X., Dickmann, C., and J. Crowcroft, "General Internet 887 Signaling Transport (GIST) over Stream Control 888 Transmission Protocol (SCTP) and Datagram Transport Layer 889 Security (DTLS)", RFC 6084, DOI 10.17487/RFC6084, January 890 2011, . 892 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 893 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 894 January 2012, . 896 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 897 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 898 January 2012, . 900 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 901 Known Attacks on Transport Layer Security (TLS) and 902 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 903 February 2015, . 905 [RFC8143] Elie, J., "Using Transport Layer Security (TLS) with 906 Network News Transfer Protocol (NNTP)", RFC 8143, 907 DOI 10.17487/RFC8143, April 2017, 908 . 910 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, 911 "Datagram Transport Layer Security (DTLS) Encapsulation of 912 SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 913 2017, . 915 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 916 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 917 . 919 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 920 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 921 . 923 [TGPP33310] 924 3GPP, "TS 33.310 - Network Domain Security (NDS); 925 Authentication Framework (AF)", 2016. 927 Appendix A. Change Log 929 [[RFC editor: please remove this before publication.]] 931 From draft-ietf-tls-oldversions-deprecate-02 to draft-ietf-tls- 932 oldversions-deprecate-03: 934 o Added 8261 to updates list based on IETF-104 meeting. 936 From draft-ietf-tls-oldversions-deprecate-01 to draft-ietf-tls- 937 oldversions-deprecate-02: 939 o Correction: 2nd list of referenced RFCs in Section 1.1 aren't 940 informatively refering to tls1.0/1.1 941 o Remove RFC7255 from updates list - datatracker has bad data 942 (spotted by Robert Sparks) 943 o Added point about RFCs 8143 and 4642 944 o Added UPDATEs for RFCs that refer to 4347 and aren't OBSOLETEd 945 o Added note about RFC8261 to see what WG want. 947 From draft-ietf-tls-oldversions-deprecate-00 to draft-ietf-tls- 948 oldversions-deprecate-01: 950 o PRs with typos and similar: so far just #1 951 o PR#2 noting msft browser announced deprecation (but this was OBE 952 as per...) 953 o Implemented actions as per IETF-103 meeting: 955 * Details about which RFC's, BCP's are affected were generated 956 using a script in the git repo: https://github.com/tlswg/ 957 oldversions-deprecate/blob/master/nonobsnorms.sh 958 * Removed the 'measurements' part 959 * Removed SHA-1 deprecation (section 8 of -00) 961 From draft-moriarty-tls-oldversions-diediedie-01 to draft-ietf-tls- 962 oldversions-deprecate-00: 964 o I-Ds became RFCs 8446/8447 (old-repo PR#4, for TLSv1.3) 965 o Accepted old-repo PR#5 fixing typos 967 From draft-moriarty-tls-oldversions-diediedie-00 to draft-moriarty- 968 tls-oldversions-diediedie-01: 970 o Added stats sent to list so far 971 o PR's #2,3 972 o a few more references 973 o added section on email 975 Authors' Addresses 977 Kathleen Moriarty 978 Dell EMC 979 176 South Street 980 Hopkinton 981 United States 983 EMail: Kathleen.Moriarty.ietf@gmail.com 985 Stephen Farrell 986 Trinity College Dublin 987 Dublin 2 988 Ireland 990 Phone: +353-1-896-2354 991 EMail: stephen.farrell@cs.tcd.ie