idnits 2.17.1 draft-popov-tls-prohibiting-rc4-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 draft header indicates that this document updates RFC4346, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (April 11, 2014) is 3658 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 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) April 11, 2014 5 Intended status: Standards Track 6 Expires: October 13, 2014 8 Prohibiting RC4 Cipher Suites 9 draft-popov-tls-prohibiting-rc4-02 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. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 13, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Changes to TLS . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 59 6.2. Informative References . . . . . . . . . . . . . . . . . 3 60 Appendix A. RC4 Cipher Suites . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 RC4 is a stream cipher described in [SCH], which is widely supported, 66 and often preferred, by TLS servers. However, RC4 has long been 67 known to have a variety of cryptographic weaknesses, e.g. [PAU], 68 [MAN], [FLU]. Recent cryptanalysis results [ALF] exploit biases in 69 the RC4 keystream to recover repeatedly encrypted plaintexts. 71 These recent results are on the verge of becoming practically 72 exploitable; currently they require 2^26 sessions or 13x2^30 73 encryptions. As a result, RC4 can no longer be seen as providing a 74 sufficient level of security for TLS sessions. 76 This document requires that TLS ([RFC5246], [RFC4346], [RFC2246]) 77 clients and servers never negotiate the use of RC4 cipher suites. 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Changes to TLS 87 Because of the deficiencies noted in Section 1: 89 o TLS clients MUST NOT include RC4 cipher suites in the ClientHello 90 message. 92 o TLS servers MUST NOT select an RC4 cipher suite when a TLS client 93 sends such a cipher suite in the ClientHello message. 95 o If the TLS client only offers RC4 cipher suites, the TLS server 96 MUST terminate the handshake. The TLS server MAY send the 97 insufficient_security fatal alert in this case. 99 Appendix A lists the RC4 cipher suites defined for TLS. 101 3. Acknowledgements 103 This document was inspired by discussions with Magnus Nystrom, Eric 104 Rescorla, Joseph Salowey, Yaron Sheffer, Nagendra Modadugu and others 105 on the TLS mailing list. 107 4. IANA Considerations 109 This memo includes no request to IANA. 111 5. Security Considerations 113 This document helps maintain the security guarantees of the TLS 114 protocol by prohibiting the use of the RC4-based cipher suites 115 (listed in Appendix A), which do not provide a sufficiently high 116 level of security. 118 6. References 120 6.1. Normative References 122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 123 Requirement Levels", BCP 14, RFC 2119, March 1997. 125 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 126 RFC 2246, January 1999. 128 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 129 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 131 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 132 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 134 6.2. Informative References 136 [ALF] AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., 137 and J. Schuldt, "On the security of RC4 in TLS and WPA. 138 USENIX Security Symposium.", 2013, . 141 [FLU] Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the 142 Key Scheduling Algorithm of RC4. Selected Areas in 143 Cryptography, pp. 1-24", 2001. 145 [MAN] Mantin, I. and A. Shamir, "A Practical Attack on Broadcast 146 RC4. FSE, pp. 152-164.", 2001. 148 [PAU] Paul, G. and S. Maitra, "Permutation after RC4 Key 149 Scheduling Reveals the Secret Key. In Proceedings of the 150 14th Workshop on Selected Areas in Cryptography (SAC), pp. 151 360-377, vol. 4876, LNCS, Springer.", 2007. 153 [SCH] Schneier, B., "Applied Cryptography: Protocols, 154 Algorithms, and Source Code in C, 2nd ed.", 1996. 156 Appendix A. RC4 Cipher Suites 158 The following cipher suites defined for TLS use RC4: 160 o TLS_RSA_WITH_RC4_128_MD5 162 o TLS_RSA_WITH_RC4_128_SHA 164 o TLS_DH_anon_WITH_RC4_128_MD5 166 o TLS_RSA_EXPORT_WITH_RC4_40_MD5 168 o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 170 Author's Address 172 Andrei Popov 173 Microsoft Corp. 174 One Microsoft Way 175 Redmond, WA 98052 176 USA 178 Email: andreipo@microsoft.com