idnits 2.17.1 draft-luis140219-curdle-rc4-die-die-die-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The draft header indicates that this document obsoletes RFC4757, but the abstract doesn't seem to directly say this. It does mention RFC4757 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC4345, but the abstract doesn't seem to directly say this. It does mention RFC4345 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC3078, but the abstract doesn't seem to directly say this. It does mention RFC3078 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC3079, but the abstract doesn't seem to directly say this. It does mention RFC3079 though, so this could be OK. -- The draft header indicates that this document updates RFC7905, but the abstract doesn't seem to directly say this. It does mention RFC7905 though, so this could be OK. -- The draft header indicates that this document updates RFC6733, but the abstract doesn't seem to directly say this. It does mention RFC6733 though, so this could be OK. -- The draft header indicates that this document updates RFC6649, but the abstract doesn't seem to directly say this. It does mention RFC6649 though, so this could be OK. -- The draft header indicates that this document updates RFC7457, but the abstract doesn't seem to directly say this. It does mention RFC7457 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2118, updated by this document, for RFC5378 checks: 1997-02-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2017) is 2482 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) == Missing Reference: 'RFCyyyy' is mentioned on line 181, but not defined == Missing Reference: 'RFC6733' is mentioned on line 310, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-curdle-des-des-des-die-die-die-03 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) L. Camara 2 Internet-Draft July 3, 2017 3 Obsoletes: 3078, 3079, 4345, 4757, 6229 4 Updates: 2118, 3501, 3961, 4120, 4253, 6150 5 Updates: 6649, 6733, 7457, 7905, xxxx 6 Intended Status: Best Current Practice 7 Expires: January 4, 2018 9 Deprecating RC4 in all IETF Protocols 10 draft-luis140219-curdle-rc4-die-die-die-02 12 [[RFC-Editor: Please replace all instances of xxxx in this document with 13 the RFC number of draft-ietf-curdle-des-des-des-die-die-die.]] 15 [[RFC-Editor: please replace the second character of my surname by 16 U+00E2 when publishing as RFC in the header and in all pages. 17 Non-ASCII characters are allowed in RFCs as per RFC 7997.]] 19 Abstract 21 RC4 is extremely weak as shown by RFC 6649 and RFC 7457, is 22 prohibited in TLS by RFC 7465, is prohibited in Kerberos by RFC xxxx 23 and it needs to be prohibited in all IETF protocols. Documents that 24 provide technology that can only use RC4 are obsoleted by this 25 document, so this document obsoletes and moves to Historic RFC 3078 26 "Microsoft Point-to-Point Encryption (MPPE) Protocol" (only supports 27 RC4, RFC 3079 that is also part of that protocol is also obsoleted), 28 RFC 4345 "Improved Arcfour Modes for the Secure Shell (SSH) Transport 29 Layer Protocol" (note Arcfour and RC4 are synonymous), RFC 4757 "The 30 RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows" (only 31 supports RC4) and RFC 6229 "Test Vectors for the Stream Cipher RC4" 32 (provides test vectors for historic cryptography). RFC 2118, 33 RFC 3501, RFC 3961, RFC 4120, RFC 4253, RFC 6150, RFC 6649, RFC 6733, 34 RFC 7457, RFC 7905 and RFC xxxx are updated to note the deprecation 35 of RC4 in all IETF protocols. (Please do not confuse RFC 4757 with 36 RFC 7457.) 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 4, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Why obsolete those RFCs and move them to Historic . . . . . . . 3 74 3. Updates to RFC 2118 . . . . . . . . . . . . . . . . . . . . . . 3 75 4. Updates to RFC 3501 . . . . . . . . . . . . . . . . . . . . . . 3 76 5. Updates to RFC 3961 . . . . . . . . . . . . . . . . . . . . . . 4 77 6. Updates to RFC 4120 . . . . . . . . . . . . . . . . . . . . . . 4 78 7. Updates to RFC 4253 . . . . . . . . . . . . . . . . . . . . . . 4 79 8. Updates to RFC 6150 . . . . . . . . . . . . . . . . . . . . . . 5 80 9. Updates to RFC 6649 . . . . . . . . . . . . . . . . . . . . . . 5 81 10. Updates to RFC 6733 . . . . . . . . . . . . . . . . . . . . . 6 82 11. Updates to RFC 7457 . . . . . . . . . . . . . . . . . . . . . 7 83 12. Updates to RFC 7465 . . . . . . . . . . . . . . . . . . . . . 7 84 13. Updates to RFC 7905 . . . . . . . . . . . . . . . . . . . . . 7 85 14. Updates to RFC xxxx . . . . . . . . . . . . . . . . . . . . . 8 86 15. Action to be taken . . . . . . . . . . . . . . . . . . . . . . 8 87 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 88 17. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 18. Acknowlegdements . . . . . . . . . . . . . . . . . . . . . . . 9 90 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 19.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 92 19.2. Informative References . . . . . . . . . . . . . . . . . . . 10 93 20. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 94 Appendix A. Status of Updated Documents as of 2017-06-17 . . . . . 11 95 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 RC4 is extremely weak [RFC6649, RFC7457, RFCxxxx] and this document 100 deprecates its use in all IETF protocols, including Kerberos and 101 Secure Shell (SSH). The reasons for obsoleting RFC 3078, RFC 3079, 102 RFC 4345 and RFC 4757 and moving them to Historic are discussed in 103 Section 2. The updates to RFC 2118, RFC 3501, RFC 3961, RFC 4120, 104 RFC 4253, RFC 6150, RFC 6649, RFC 6733, RFC 7457, RFC 7905 and 105 RFC xxxx and the reasons for doing them are specified in sections 3, 106 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 and 14, respectively. The status of 107 the updated RFCs as of the writing of this document is available in 108 Appendix A. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in 113 BCP 14 [RFC2119, RFC8174]. 115 2. Why obsolete those RFCs and move them to Historic 117 RFC 3078 is no longer used by supported Microsoft Windows versions 118 and is moved to Historic and obsoleted by this document as it only 119 supports RC4 for encryption. RFC 2118 is updated to note the 120 moving of RFC 3078 (that updated RFC 2118) to Historic and its 121 obsoleting. RFC 3079, that is effectively part of RFC 3078, is also 122 moved to Historic as it only supports RC4 for encryption. 124 RFC 4345 defines the "arcfour-128" and "arcfour-256" modes for Secure 125 Shell (SSH), and is moved to Historic as RC4 is extremely 126 weak [RFC6649, RFC7457, RFCxxxx] and there is research that is at 127 least 5 years old that totally breaks all practical usage of 128 RC4 [RFC6649]. 130 RFC 4757 is obsoleted and moved to Historic as it is no longer used 131 by supported Microsoft Windows versions (support for Windows XP ended 132 8 April 2014, any unofficial support for officially unsupported 133 Microsoft Windows versions will certainly remove RC4) and specifies 134 RC4-HMAC as used by Microsoft Windows in Kerberos, that should have 135 been obsoleted, not updated, by RFC 6649. RFC xxxx also obsoletes 136 RFC 4757. Additionally, MD4 is extremely weak and not 137 one-way [RFC6150] and this is another reason to move RFC 4757 to 138 Historic, as well as the myriads of other reasons specified 139 in [RFC6150]. 141 RFC 6229 provides test vectors for RC4 and is obsoleted and moved to 142 Historic by this document as RC4 is deprecated in all IETF protocols. 144 3. Updates to RFC 2118 146 RFC 2118 is updated to note the obsoleting of RFC 3078 and the 147 moving of RFC 3078 to Historic (see Section 2). 149 4. Updates to RFC 3501 151 In Section 11.1 of [RFC3501], it is stated that: 153 """ 154 IMAP client and server implementations MUST implement the 155 TLS_RSA_WITH_RC4_128_MD5 {TLS} cipher suite, and SHOULD implement the 156 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA {TLS} cipher suite. This is 157 important as it assures that any two compliant implementations can be 158 configured to interoperate. All other cipher suites are OPTIONAL. 159 Note that this is a change from section 2.1 of {IMAP_TLS}. 160 """ 162 [[References were replaced with curly braces to avoid nits. When 163 publishing, revert back to references.]] 165 The above paragraph of [RFC3501] required that implementations of 166 IMAP clients and servers implement a RC4 cipher suite in TLS 167 (contradicts [RFC7465]) and recommends implementing a weak cipher 168 suite (DSA is not recommended by some sources and 3DES is used in 169 the suite). Unfortunately, at the time of writing of RFC 3501, 170 AES cipher suites were extremely new (the first AES cipher suites 171 were defined in RFC 3268, published in June 2002), less than 1 year 172 old and the strongest choice they have come up with at the time was 173 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 175 As the document is over 14 years old, the above paragraph of [RFC3501] 176 is replaced with the following paragraph: 178 """ 179 IMAP client and server implementations were formerly required to 180 implement TLS_RSA_WITH_RC4_128_MD5 {TLS}, an extremely weak cipher 181 suite [RFC6151, RFC6649, RFC7457, RFCxxxx, RFCyyyy] that TLS clients 182 MUST NOT implement per [RFC7465]. Compatibility requirements were 183 removed in the grounds of security, and all clients and servers 184 SHOULD implement TLS 1.2 {TLS} and the 185 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 {TLS} cipher suite. 186 """ 188 The TLS reference in [RFC3501] should be replaced with a reference to 189 RFC 5246, and references to RFC 6151, RFC 6649, RFC 7457, RFC 7465, 190 RFC xxxx and this document (as RFC yyyy) should be added. 192 5. Updates to RFC 3961 194 RFC 3961 is updated to note the deprecation of rc4-hmac and 195 rc4-hmac-exp (referred to in Section 8 of [RFC3961]). rc4-hmac is 196 NOT RECOMMENDED by [RFCxxxx] and rc4-hmac-exp is NOT RECOMMENDED 197 by [RFC6649]. 199 6. Updates to RFC 4120 201 RFC 4120 is updated to note the deprecation of rc4-hmac and 202 rc4-hmac-exp. 204 7. Updates to RFC 4253 206 RFC 4253 is updated to note the deprecation of arcfour and 3des-cbc. 208 This document changes "OPTIONAL" to "NOT RECOMMENDED" for arcfour and 209 "REQUIRED" to "OPTIONAL" for 3des-cbc in the table of 210 Section 6.3 of [RFC4253] as 3DES is weak and maintaining the 211 requirement will compromise systems. [RFC4253] was published in 2006, 212 11 years ago, and states that """At some future time, it is expected 213 that another algorithm, one with better strength, will become so 214 prevalent and ubiquitous that the use of "3des-cbc" will be 215 deprecated by another STANDARDS ACTION.""" 217 The "future time" referred to by [RFC4253] is set to 2017, the 218 "STANDARDS ACTION" is set to the publication of this document and 219 the "algorithm" is set to the Advanced Encryption Standard (AES), as 220 AES is ubiquitous in Kerberos implementations (see Section 11). 222 The paragraph on RC4 (called "arcfour" in [RFC4253]) in 223 Section 6.3 of [RFC4253] currently reads: 224 """ 225 The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. 226 The Arcfour cipher is believed to be compatible with the RC4 cipher 227 [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and 228 should be used with caution. 229 """ 231 It should read: 232 """ 233 The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. 234 The Arcfour cipher is believed to be compatible with the RC4 cipher 235 [SCHNEIER]. Arcfour (and RC4) are extremely weak [RFC6649, RFC7457, 236 RFCxxxx, RFCyyyy] and therefore their use is NOT RECOMMENDED. 237 """ 239 References to RFC 6649, RFC 7457, RFC xxxx and this document (the 240 reference to this document is RFCyyyy in the above paragraph) should 241 be added to Section 6.3 of [RFC4253]. 243 8. Updates to RFC 6150 245 RFC 6150 moves MD4 to Historic. Note the RFC contains a typo: "MD2" 246 should be "MD4". RFC 6150 references RFC 4757, obsoleted by this 247 document, as using MD4. The expression "with the one exception of 248 Microsoft's use of MD4 as part of RC4-HMAC in Windows,", as well as 249 all expressions indicating algorithms using RC4 are a problem to the 250 deprecation of MD4, should be removed from Section 4 of [RFC6150]. 252 9. Updates to RFC 6649 254 RFC 6649, also known as BCP 179, deprecates DES, RC4-HMAC-EXP and 255 other weak cryptography in Kerberos. It is updated to note the 256 deprecation of rc4-hmac and the deprecation of RC4 in all IETF 257 protocols. 259 The security considerations of [RFC6649] (Section 6 of [RFC6649]) 260 read, in their last paragraph: 262 """ 263 The security considerations of [RFC4757] continue to apply to 264 RC4-HMAC, including the known weaknesses of RC4 and MD4, and this 265 document does not change the Informational status of [RFC4757] for 266 now. The main reason to not actively discourage the use of RC4-HMAC 267 is that it is the only encryption type that interoperates with older 268 versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. 269 These older versions of Microsoft Windows will likely be in use until 270 at least 2015. 271 """ 273 This is updated to note that Windows XP is without official support 274 for 3 years (support for Windows XP ended 8 April 2014). 276 An important quote from [RFC6649] (Section 6 of [RFC6649]): 277 """ 278 Removing support for single DES improves security because DES is 279 considered to be insecure. RC4-HMAC-EXP has a similarly inadequate 280 key size, so removing support for it also improves security. 281 """ 283 10. Updates to RFC 6733 285 Section 13.1. of [RFC6733] currently reads: 286 """ 287 Diameter nodes MUST be able to negotiate the following TLS/TCP and 288 DTLS/SCTP cipher suites: 290 TLS_RSA_WITH_RC4_128_MD5 291 TLS_RSA_WITH_RC4_128_SHA 292 TLS_RSA_WITH_3DES_EDE_CBC_SHA 294 Diameter nodes SHOULD be able to negotiate the following TLS/TCP and 295 DTLS/SCTP cipher suite: 297 TLS_RSA_WITH_AES_128_CBC_SHA 299 Note that it is quite possible that support for the 300 TLS_RSA_WITH_AES_128_CBC_SHA cipher suite will be REQUIRED at some 301 future date. Diameter nodes MAY negotiate other TLS/TCP and DTLS/ 302 SCTP cipher suites. 303 """ 305 The above paragraphs required that clients implement two RC4 cipher 306 suites and a 3DES cipher suite (but recommends implementing an AES 307 cipher suite). 309 RFC 6733 was published in October 2012, and the above paragraphs 310 of [RFC6733] are to be replaced with: 312 """ 313 Diameter nodes were formerly required to implement insecure RC4 314 cipher suites and weak 3DES cipher suites. RC4 MUST NOT be used 315 because it is prohibited by RFC 7465. 317 Diameter nodes MUST support at least one of the following cipher 318 suites: 320 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 321 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 322 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 323 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 324 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 325 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 326 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 327 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 328 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 329 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 331 TLS_RSA_WITH_AES_128_CBC_SHA was not chosen to be absolutely required 332 as Diameter nodes may require all connections to use forward secrecy 333 by only implementing cipher suites with forward secrecy. 334 TLS_RSA_WITH_AES_128_CBC_SHA is not a forward secrecy cipher suite 335 because all connections can be decrypted once the private RSA key is 336 known by an attacker. 337 """ 339 Several choices were given because of patent concerns with Elliptic 340 Curve Cryptography (ECC) and problems of older implementations with 341 ECC and GCM cipher suites. 343 11. Updates to RFC 7457 345 RFC 7457, an Informational RFC describing attacks against Transport 346 Layer Security (TLS) and Datagram Transport Layer Security (DTLS), is 347 updated to note the deprecation of RC4 in all IETF protocols. 349 12. Updates to RFC 7465 351 RFC 7465 prohibits RC4 cipher suites in Transport Layer Security 352 (TLS) and is updated to note the deprecation of RC4 in all IETF 353 protocols. 355 13. Updates to RFC 7905 357 RFC 7905, describing the ChaCha20-Poly1305 stream cipher to replace 358 RC4 in Transport Layer Security (TLS), is updated to note the 359 deprecation of RC4 in all IETF protocols, including TLS. [RFC7465], 360 that prohibited RC4 cipher suites, did not update RFC 7905, so this 361 document will do so. 363 14. Updates to RFC xxxx 365 RFC xxxx deprecates 3DES and RC4 in Kerberos, obsoletes RFC 4757 and 366 updates RFC 3961, and is updated by this document to note the 367 moving of RC4 RFCs (RFC 4345 and RFC 6229) and Microsoft technology 368 dependent on RC4 (RFC 3078 and RFC 4757). 370 An important quote from [RFCxxxx] (Section 5.4 of [RFCxxxx]): 371 """ 372 Fortuntately, modern (i.e., supported) Kerberos implementations 373 support a secure alternative to RC4, in the form of AES. Windows has 374 supported AES since 2007-2008 with the release of Windows Vista and 375 Server 2008, respectively; MIT Kerberos [MITKRB5] has fully supported 376 AES (including the GSSAPI mechanism) since 2004 with the release of 377 version 1.3.2; Heimdal [HEIMDAL] has fully supported AES since 2005 378 with the release of version 0.7. Though there may still be issues 379 running ten-year-old unsupported software in mixed environments with 380 new software, issues of that sort seem unlikely to be unique to 381 Kerberos, and the aministrators of such environments are expected to 382 be capable of devising workarounds. 383 """ 384 (note the quote contains typos: "Fortuntately" and "aministrators") 386 15. Action to be taken 388 RC4 MUST NOT be used in new implementations of IETF protocols, and 389 RC4 MUST be eliminated as fast as possible from the existing Internet 390 infrastructure, as RC4 is extremely weak [RFC6649, RFC7457, RFCxxxx]. 391 New RFCs MAY use the phrase "RC4 is extremely weak [RFC6649, RFC7457, 392 RFCxxxx]" with references to RFC 6649, RFC 7457 and RFC xxxx. Whether 393 the references to these documents is normative or informative is 394 determined by BCP 9 and BCP 97, whose relevant documents for this 395 purpose are RFC 2026, RFC 3967, RFC 4897, RFC 6410 and RFC 8067. 397 Microsoft Corporation SHOULD take action to eradicate RC4 in all 398 its software and systems. 400 New IETF protocols MUST NOT allow RC4, and new versions of existing 401 IETF protocols MUST either not allow RC4 or recommend not to use RC4 402 (for example, using "NOT RECOMMENDED" or "SHOULD NOT"). 404 16. IANA Considerations 406 IANA may need to take action as the status for RC4 and 3DES 407 algorithms for Secure Shell (SSH) is changed by this document 408 (see Section 6, that updates [RFC4253]). 410 17. Security Considerations 412 This document deprecates RC4, that is obsolete cryptography, and 413 several attacks that render it useless have been published [RFC6649]. 414 Refer to Section 5 of [RFCxxxx] for further security considerations. 416 18. Acknowledgements 418 [[RFC-Editor: When possible, add native names according to the 419 conventions of RFC 7997.]] 421 Thanks to the following people for writing reference material: 423 * Sean Turner and Lily Chen for writing RFC 6151, that contains 424 updated security considerations for MD5 and HMAC-MD5. 426 * Love Hornquist Astrand and Tom Yu for writing RFC 6649, that 427 deprecates weak cryptographic algorithms in Kerberos. 429 * Yaron Sheffer, Ralph Holz and Peter Saint-Andre for writing 430 RFC 7457, that summarises known attacks against Transport Layer 431 Security (TLS). 433 * Andrei Popov for writing RFC 7465, that prohibits RC4 cipher 434 suites in Transport Layer Security (TLS). 436 * Julien Elie for sending me an email about the requirements to 437 implement RC4 cipher suites in RFC 3501 and RFC 6733. 439 Also thanks to SSL Labs for capping server grades to B (RC4 only used 440 with older protocols) and C (RC4 used with modern protocols) when 441 servers support RC4, and flagging cipher suites and clients using RC4 442 with a red colour (for INSECURE and RC4). You can test any server at 443 . 445 Refer to the acknowledgements section of RFC 6649, RFC 7457 and 446 RFC xxxx for further acknowledgements. 448 19. References 450 19.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC- 456 EXP, and Other Weak Cryptographic Algorithms in Kerberos", 457 BCP 179, RFC 6649, July 2012. 459 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 460 RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 462 [RFCxxxx] Kaduk, B., and M. Short, "Deprecate 3DES and RC4 in 463 Kerberos", draft-ietf-curdle-des-des-des-die-die-die-03, 464 Work in Progress. 466 19.2. Informative References 468 [HEIMDAL] Heimdal Project, "Heimdal Kerberos Implementation", April 469 2017, . 471 [MITKRB5] MIT, "MIT Kerberos Implementation", March 2017, 472 . 474 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - Version 475 4rev1", RFC 3501, March 2003. 477 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 478 Kerberos 5", RFC 3961, February 2005. 480 [RFC4253] Ylonen, T., and C. Lonvick, Ed., "The Secure Shell (SSH) 481 Transport Layer Protocol", RFC 4253, January 2006. 483 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC 484 Kerberos Encryption Types Used by Microsoft Windows", 485 RFC 4757, December 2606. 487 [RFC6150] Turner, S., and L. Chen, "MD4 to Historic Status", 488 RFC 6150, March 2011. 490 [RFC6151] Turner, S., and L. Chen, "Updated Security Considerations 491 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 492 RFC 6151, March 2011. 494 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 495 Known Attacks on Transport Layer Security (TLS) and 496 Datagram TLS (DTLS)", RFC 7457, February 2015. 498 [RFC7465] Popov, A., "Deprecating RC4 Cipher Suites", RFC 7465, 499 February 2015. 501 [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: 502 protocols algorithms and source in code in C", John Wiley 503 and Sons, New York, NY, 1996. 505 [[RFC-Editor: please replace the 'i' in my name by U+00ED and the 506 first 'a' in the surname by U+00E2, as non-ASCII characters are 507 allowed as per RFC 7997]] 509 20. Author's Address 511 Luis Camara 513 EMail: 515 Appendix A. Status of Updated Documents as of 2017-06-24 517 [[RFC-Editor: Please replace with updated data when publishing as RFC 518 and replace "2017-06-24" by the date of publishing. 519 Leave the table below in a page of its own.]] 520 +----------+-----------------------+--------------------------------+ 521 | RFC #### | Status | Updated by | 522 +----------+-----------------------+--------------------------------+ 523 | RFC 2118 | Informational | RFC 3078 | 524 +----------+-----------------------+--------------------------------+ 525 | | | RFC 4466, RFC 4469, RFC 4551, | 526 | RFC 3501 | Proposed Standard | RFC 5032, RFC 5182, RFC 5738, | 527 | | | RFC 6186, RFC 6858, RFC 7817 | 528 +----------+-----------------------+--------------------------------+ 529 | RFC 3961 | Proposed Standard | RFC xxxx | 530 +----------+-----------------------+--------------------------------+ 531 | | | RFC 4537, RFC 5021, RFC 5896, | 532 | RFC 4120 | Proposed Standard | RFC 6111, RFC 6112, RFC 6113, | 533 | | | RFC 6649, RFC 6806, RFC 7751, | 534 | | | RFC 8062, RFC 8129 | 535 +----------+-----------------------+--------------------------------+ 536 | RFC 4253 | Proposed Standard | RFC 6668 | 537 +----------+-----------------------+--------------------------------+ 538 | RFC 6150 | Informational | | 539 +----------+-----------------------+--------------------------------+ 540 | RFC 6649 | Best Current Practice | | 541 | | (BCP 179) | | 542 +----------+-----------------------+--------------------------------+ 543 | RFC 6733 | Proposed Standard | RFC 7075 | 544 +----------+-----------------------+--------------------------------+ 545 | RFC 7457 | Informational | | 546 +----------+-----------------------+--------------------------------+ 547 | RFC 7465 | Proposed Standard | | 548 +----------+-----------------------+--------------------------------+ 549 | RFC 7905 | Proposed Standard | | 550 +----------+-----------------------+--------------------------------+ 551 | RFC xxxx | Best Current Practice | This draft is [RFCxxxx] | 552 | | | | 553 +----------+-----------------------+--------------------------------+ 555 Appendix B. Changelog 557 [[RFC-Editor: please remove this section when publishing.]] 559 02 - changed title to "Deprecating RC4 in all IETF Protocols", changed 560 the header of all pages to "Deprecating RC4 in all Protocols", 561 updated RFC 3501 and RFC 6733, simplified the reference to 562 draft-ietf-curdle-des-des-des-die-die-die to a simple "Work in 563 Progress" reference and fixed typos. 565 01 - explained reasons for updating RFC 7905 and added an informative 566 reference to RFC 4757 to take away a missing reference warning. 568 00 - first version. [RFCxxxx] is a reference to 569 draft-ietf-curdle-des-des-des-die-die-die. The quote in 570 Section 11 is from version 03 of this draft (posted 2017-06-15)