idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC4345, but the header doesn't have an 'Obsoletes:' line to match this. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to directly say this. It does mention RFC3501 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 RFC4253, but the abstract doesn't seem to directly say this. It does mention RFC4253 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 RFC3501, updated by this document, for RFC5378 checks: 1997-09-12) (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 1997-03-26) -- 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 (August 8, 2017) is 2452 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 147, but not defined ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-05) exists of draft-ietf-curdle-des-des-des-die-die-die-04 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 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 August 8, 2017 3 Obsoletes: 4345 4 Updates: 3501, 4253, 6649, 6733 5 Intended Status: Best Current Practice 6 Expires: February 9, 2018 8 Deprecating RC4 in all IETF Protocols 9 draft-ietf-curdle-rc4-die-die-die-02 11 [[RFC-Editor: Please replace all instances of xxxx in this document with 12 the RFC number of draft-ietf-curdle-des-des-des-die-die-die.]] 14 [[RFC-Editor: please replace the second character of my surname by 15 U+00E2 when publishing as RFC in the header and in all pages. 16 Non-ASCII characters are allowed in RFCs as per RFC 7997.]] 18 Abstract 20 RC4 is extremely weak as shown by RFC 6649 and RFC 7457, is 21 prohibited in TLS by RFC 7465, is prohibited in Kerberos by RFC xxxx 22 and it needs to be prohibited in all IETF protocols. This document 23 obsoletes RFC 4345 "Improved Arcfour Modes for the Secure Shell (SSH) 24 Transport Layer Protocol" (note Arcfour and RC4 are synonymous). 25 RFC 3501, RFC 4253, RFC 6649 and RFC 6733 are updated to note the 26 deprecation of RC4 in all IETF protocols. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 4, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Why obsolete RFC 4345 . . . . . . . . . . . . . . . . . . . . . 2 64 3. Updates to RFC 3501 . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Updates to RFC 4253 . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Updates to RFC 6649 . . . . . . . . . . . . . . . . . . . . . . 4 67 6. Updates to RFC 6733 . . . . . . . . . . . . . . . . . . . . . . 4 68 7. Action to be taken . . . . . . . . . . . . . . . . . . . . . . 5 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 71 10. Acknowlegdements . . . . . . . . . . . . . . . . . . . . . . . 5 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 74 11.2. Informative References . . . . . . . . . . . . . . . . . . . 6 75 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 76 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 RC4 is extremely weak [RFC6649] [RFC7457] [RFCxxxx] and this document 81 deprecates its use in all IETF protocols, including Kerberos and 82 Secure Shell (SSH). The reasons for obsoleting RFC 4345 are discussed 83 in Section 2. The updates to RFC 3501, RFC 4253, RFC 6649 and RFC 84 RFC 6733 and the reasons for doing them are specified in sections 3, 85 4, 5 and 6, respectively. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in 90 BCP 14 [RFC2119, RFC8174]. 92 2. Why obsolete RFC 4345 94 RFC 4345 defines the "arcfour-128" and "arcfour-256" modes for Secure 95 Shell (SSH), and is moved to Historic as RC4 is extremely 96 weak [RFC6649, RFC7457, RFCxxxx] and there is research that is at 97 least 5 years old that totally breaks all practical usage of 98 RC4 [RFC6649]. 100 3. Updates to RFC 3501 102 The second paragraph of [RFC3501] required that implementations of 103 IMAP clients and servers implement a RC4 cipher suite in TLS 104 (contradicts [RFC7465]) and recommends implementing a weak cipher 105 suite (3DES is used in the suite). Unfortunately, at the time of 106 writing of RFC 3501, AES cipher suites were extremely new (the first 107 AES cipher suites were defined in RFC 3268, published in June 2002), 108 less than 1 year old and the strongest choice they have come up with 109 at the time was TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 111 As the document is over 14 years old, the second paragraph of 112 Section 11.1 of [RFC3501] is replaced with the following paragraph: 114 """ 115 IMAP client and server implementations were formerly required to 116 implement TLS_RSA_WITH_RC4_128_MD5 {TLS}, an extremely weak cipher 117 suite [RFC6151] [RFC6649] [RFC7457] [RFCxxxx] [RFCyyyy] that TLS 118 clients MUST NOT implement per [RFC7465]. Compatibility requirements 119 were removed in the grounds of security, and all clients and servers 120 SHOULD comply to [RFC7525]. 121 """ 123 The TLS reference in [RFC3501] should be replaced with a reference to 124 RFC 5246, and references to RFC 6151, RFC 6649, RFC 7457, RFC 7465, 125 RFC xxxx and this document (as RFC yyyy) should be added. 127 4. Updates to RFC 4253 129 RFC 4253 is updated to note the deprecation of arcfour and 3des-cbc. 131 This document changes "OPTIONAL" to "NOT RECOMMENDED" for arcfour and 132 "REQUIRED" to "OPTIONAL" for 3des-cbc in the table of 133 Section 6.3 of [RFC4253] as 3DES is weak and maintaining the 134 requirement will compromise systems. [RFC4253] was published in 2006, 135 11 years ago, and states that """At some future time, it is expected 136 that another algorithm, one with better strength, will become so 137 prevalent and ubiquitous that the use of "3des-cbc" will be 138 deprecated by another STANDARDS ACTION.""" 140 The "future time" referred to by [RFC4253] is set to 2017, the 141 "STANDARDS ACTION" is set to the publication of this document and 142 the "algorithm" is set to the Advanced Encryption Standard (AES), as 143 AES is ubiquitous in Kerberos implementations (see Section 11). 145 The last sentence of the paragraph on RC4 (called "arcfour" 146 in [RFC4253]) in Section 6.3 of [RFC4253] should read: "Arcfour (and 147 RC4) are extremely weak [RFC6649] [RFC7457] [RFCxxxx] [RFCyyyy] and 148 therefore their use is NOT RECOMMENDED." 149 References to RFC 6649, RFC 7457, RFC xxxx and this document (the 150 reference to this document is RFCyyyy in the above paragraph) should 151 be added to Section 6.3 of [RFC4253]. 153 5. Updates to RFC 6649 155 RFC 6649, also known as BCP 179, deprecates DES, RC4-HMAC-EXP and 156 other weak cryptography in Kerberos. It is updated to note the 157 deprecation of rc4-hmac and the deprecation of RC4 in all IETF 158 protocols. 160 The security considerations of [RFC6649] (Section 6 of [RFC6649]) 161 read, in their last paragraph: 163 """ 164 The security considerations of [RFC4757] continue to apply to 165 RC4-HMAC, including the known weaknesses of RC4 and MD4, and this 166 document does not change the Informational status of [RFC4757] for 167 now. The main reason to not actively discourage the use of RC4-HMAC 168 is that it is the only encryption type that interoperates with older 169 versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. 170 These older versions of Microsoft Windows will likely be in use until 171 at least 2015. 172 """ 174 This is updated to note that Windows XP is without official support 175 for 3 years (support for Windows XP ended 8 April 2014). 177 6. Updates to RFC 6733 179 Section 13.1 of [RFC6733] required that clients implement two RC4 180 cipher suites and a 3DES cipher suite (but recommends implementing an 181 AES cipher suite). 183 RFC 6733 was published in October 2012, and all paragraphs but the 184 last of Section 13.1 of [RFC6733] are to be replaced with: 186 """ 187 Diameter nodes were formerly required to implement insecure RC4 188 cipher suites and weak 3DES cipher suites. RC4 MUST NOT be used 189 because it is prohibited by RFC 7465. 191 Diameter nodes MUST comply to [RFC7525]. 193 TLS_RSA_WITH_AES_128_CBC_SHA was not chosen to be absolutely required 194 as Diameter nodes may require all connections to use forward secrecy 195 by only implementing cipher suites with forward secrecy. 196 TLS_RSA_WITH_AES_128_CBC_SHA is not a forward secrecy cipher suite 197 because all connections can be decrypted once the private RSA key is 198 known by an attacker. 199 """ 201 7. Action to be taken 203 RC4 MUST NOT be used in new implementations of IETF protocols, and 204 RC4 MUST be eliminated as fast as possible from the existing Internet 205 infrastructure, as RC4 is insecure [RFC6649] [RFC7457] [RFCxxxx]. 207 Vendors SHOULD take action to eradicate RC4 in all their software 208 and systems. 210 New IETF protocols MUST NOT allow RC4, and new versions of existing 211 IETF protocols MUST either not allow RC4 or recommend not to use RC4 212 (for example, using "NOT RECOMMENDED" or "SHOULD NOT"). 214 8. IANA Considerations 216 IANA may need to take action as the status for RC4 and 3DES 217 algorithms for Secure Shell (SSH) is changed by this document 218 (see Section 6, that updates [RFC4253]). 220 9. Security Considerations 222 This document deprecates RC4, that is obsolete cryptography, and 223 several attacks that render it useless have been published [RFC6649]. 224 Refer to Section 5 of [RFCxxxx] for further security considerations. 226 10. Acknowledgements 228 [[RFC-Editor: When possible, add native names according to the 229 conventions of RFC 7997.]] 231 Thanks to the following people: 233 * Sean Turner and Lily Chen for writing RFC 6151, that contains 234 updated security considerations for MD5 and HMAC-MD5. 236 * Love Hornquist Astrand and Tom Yu for writing RFC 6649, that 237 deprecates weak cryptographic algorithms in Kerberos. 239 * Yaron Sheffer, Ralph Holz and Peter Saint-Andre for writing 240 RFC 7457, that summarises known attacks against Transport Layer 241 Security (TLS), and RFC 7525, that provides recommendations for 242 the use of TLS and Datagram Transport Layer Security (DTLS). 244 * Andrei Popov for writing RFC 7465, that prohibits RC4 cipher 245 suites in Transport Layer Security (TLS). 247 * Julien Elie for sending me an email about the requirements to 248 implement RC4 cipher suites in RFC 3501 and RFC 6733. 250 Also thanks to SSL Labs for capping server grades to B (RC4 only used 251 with older protocols) and C (RC4 used with modern protocols) when 252 servers support RC4, and flagging cipher suites and clients using RC4 253 with a red colour (for INSECURE and RC4). You can test any server at 254 . 256 Refer to the acknowledgements section of RFC 6649, RFC 7457 and 257 RFC xxxx for further acknowledgements. 259 11. References 261 11.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC- 267 EXP, and Other Weak Cryptographic Algorithms in Kerberos", 268 BCP 179, RFC 6649, July 2012. 270 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 271 "Recommendations for Secure Use of Transport Layer 272 Security (TLS) and Datagram Transport Layer Security 273 (DTLS)", BCP 195, RFC 7525, May 2015. 275 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 276 RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 278 [RFCxxxx] Kaduk, B., and M. Short, "Deprecate 3DES and RC4 in 279 Kerberos", draft-ietf-curdle-des-des-des-die-die-die-04, 280 Work in Progress. 282 11.2. Informative References 284 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - Version 285 4rev1", RFC 3501, March 2003. 287 [RFC4253] Ylonen, T., and C. Lonvick, Ed., "The Secure Shell (SSH) 288 Transport Layer Protocol", RFC 4253, January 2006. 290 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC 291 Kerberos Encryption Types Used by Microsoft Windows", 292 RFC 4757, December 2006. 294 [RFC6151] Turner, S., and L. Chen, "Updated Security Considerations 295 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 296 RFC 6151, March 2011. 298 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 299 Ed., "Diameter Base Protocol", RFC 6733, October 2012. 301 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 302 Known Attacks on Transport Layer Security (TLS) and 303 Datagram TLS (DTLS)", RFC 7457, February 2015. 305 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 306 February 2015. 308 [[RFC-Editor: please replace the 'i' in my name by U+00ED and the 309 first 'a' in the surname by U+00E2, as non-ASCII characters are 310 allowed as per RFC 7997]] 312 12. Author's Address 314 Luis Camara 316 EMail: 318 Appendix A. Changelog 320 [[RFC-Editor: please remove this section when publishing.]] 322 WG draft (draft-ietf-curdle-rc4-die-die-die): 324 02 - addressed Todd Short's concerns. 326 01 - massive simplification: removed informational updates, removed 327 all Pre-5378 Material, retracted all "Obsoletes:" except for 328 RFC 4345, removed Appendix A and renamed changelog to Appendix A. 330 00 - dummy update to get the draft into the curdle WG. 332 Individual draft (draft-luis140219-curdle-rc4-die-die-die): 334 02 - changed title to "Deprecating RC4 in all IETF Protocols", changed 335 the header of all pages to "Deprecating RC4 in all Protocols", 336 updated RFC 3501 and RFC 6733, simplified the reference to 337 draft-ietf-curdle-des-des-des-die-die-die to a simple "Work in 338 Progress" reference and fixed typos. 340 01 - explained reasons for updating RFC 7905 and added an informative 341 reference to RFC 4757 to take away a missing reference warning. 343 00 - first version. [RFCxxxx] is a reference to 344 draft-ietf-curdle-des-des-des-die-die-die. The quote in 345 Section 11 is from version 03 of this draft (posted 2017-06-15)