idnits 2.17.1 draft-ietf-tls-prohibiting-rc4-01.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 ([RFC5246], [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 RFC2246, but the abstract doesn't seem to directly say this. It does mention RFC2246 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 (Using the creation date from RFC2246, updated by this document, for RFC5378 checks: 1996-12-03) -- 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 (October 1, 2014) is 3466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Popov 3 Internet-Draft Microsoft Corp. 4 Updates: 5246,4346,2246 (if approved) October 1, 2014 5 Intended status: Standards Track 6 Expires: April 4, 2015 8 Prohibiting RC4 Cipher Suites 9 draft-ietf-tls-prohibiting-rc4-01 11 Abstract 13 This document requires that Transport Layer Security (TLS) clients 14 and servers never negotiate the use of RC4 cipher suites when they 15 establish connections. This applies to all TLS versions, and updates 16 [RFC5246], [RFC4346], and [RFC2246]. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 4, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Changes to TLS . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 60 6.2. Informative References . . . . . . . . . . . . . . . . . 3 61 Appendix A. RC4 Cipher Suites . . . . . . . . . . . . . . . . . 4 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 RC4 is a stream cipher described in [SCH], which is widely supported, 67 and often preferred, by TLS servers. However, RC4 has long been 68 known to have a variety of cryptographic weaknesses, e.g. [PAU], 69 [MAN], [FLU]. Recent cryptanalysis results [ALF] exploit biases in 70 the RC4 keystream to recover repeatedly encrypted plaintexts. 72 These recent results are on the verge of becoming practically 73 exploitable; currently they require 2^26 sessions or 13x2^30 74 encryptions. As a result, RC4 can no longer be seen as providing a 75 sufficient level of security for TLS sessions. 77 This document requires that TLS ([RFC5246], [RFC4346], [RFC2246]) 78 clients and servers never negotiate the use of RC4 cipher suites. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Changes to TLS 88 Because of the deficiencies noted in Section 1: 90 o TLS clients MUST NOT include RC4 cipher suites in the ClientHello 91 message. 93 o TLS servers MUST NOT select an RC4 cipher suite when a TLS client 94 sends such a cipher suite in the ClientHello message. 96 o If the TLS client only offers RC4 cipher suites, the TLS server 97 MUST terminate the handshake. The TLS server MAY send the 98 insufficient_security fatal alert in this case. 100 Appendix A lists the RC4 cipher suites defined for TLS. 102 3. Acknowledgements 104 This document was inspired by discussions with Magnus Nystrom, Eric 105 Rescorla, Joseph Salowey, Yaron Sheffer, Nagendra Modadugu and others 106 on the TLS mailing list. 108 4. IANA Considerations 110 This memo includes no request to IANA. 112 5. Security Considerations 114 This document helps maintain the security guarantees of the TLS 115 protocol by prohibiting the use of the RC4-based cipher suites 116 (listed in Appendix A), which do not provide a sufficiently high 117 level of security. 119 6. References 121 6.1. Normative References 123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 124 Requirement Levels", BCP 14, RFC 2119, March 1997. 126 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 127 RFC 2246, January 1999. 129 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 130 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 132 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 133 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 135 6.2. Informative References 137 [ALF] AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., 138 and J. Schuldt, "On the security of RC4 in TLS and WPA. 139 USENIX Security Symposium.", 2013, 140 . 143 [FLU] Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the 144 Key Scheduling Algorithm of RC4. Selected Areas in 145 Cryptography, pp. 1-24", 2001. 147 [MAN] Mantin, I. and A. Shamir, "A Practical Attack on Broadcast 148 RC4. FSE, pp. 152-164.", 2001. 150 [PAU] Paul, G. and S. Maitra, "Permutation after RC4 Key 151 Scheduling Reveals the Secret Key. In Proceedings of the 152 14th Workshop on Selected Areas in Cryptography (SAC), pp. 153 360-377, vol. 4876, LNCS, Springer.", 2007. 155 [SCH] Schneier, B., "Applied Cryptography: Protocols, 156 Algorithms, and Source Code in C, 2nd ed.", 1996. 158 Appendix A. RC4 Cipher Suites 160 The following cipher suites defined for TLS use RC4: 162 o TLS_RSA_EXPORT_WITH_RC4_40_MD5 164 o TLS_RSA_WITH_RC4_128_MD5 166 o TLS_RSA_WITH_RC4_128_SHA 168 o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 170 o TLS_DH_anon_WITH_RC4_128_MD5 172 o TLS_KRB5_WITH_RC4_128_SHA 174 o TLS_KRB5_WITH_RC4_128_MD5 176 o TLS_KRB5_EXPORT_WITH_RC4_40_SHA 178 o TLS_KRB5_EXPORT_WITH_RC4_40_MD5 180 o TLS_PSK_WITH_RC4_128_SHA 182 o TLS_DHE_PSK_WITH_RC4_128_SHA 184 o TLS_RSA_PSK_WITH_RC4_128_SHA 186 o TLS_ECDH_ECDSA_WITH_RC4_128_SHA 188 o TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 190 o TLS_ECDH_RSA_WITH_RC4_128_SHA 191 o TLS_ECDHE_RSA_WITH_RC4_128_SHA 193 o TLS_ECDH_anon_WITH_RC4_128_SHA 195 o TLS_ECDHE_PSK_WITH_RC4_128_SHA 197 Author's Address 199 Andrei Popov 200 Microsoft Corp. 201 One Microsoft Way 202 Redmond, WA 98052 203 USA 205 Email: andreipo@microsoft.com