idnits 2.17.1 draft-bmoeller-tls-downgrade-scsv-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 RFC5246, but the abstract doesn't seem to directly say this. It does mention RFC5246 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 (June 1, 2014) is 3614 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6101' is mentioned on line 219, but not defined ** 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 (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Moeller 3 Internet-Draft A. Langley 4 Updates: 2246,4346,5246 Google 5 (if approved) June 1, 2014 6 Intended status: Standards Track 7 Expires: December 3, 2014 9 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol 10 Downgrade Attacks 11 draft-bmoeller-tls-downgrade-scsv-02 13 Abstract 15 This document defines a Signaling Cipher Suite Value (SCSV) that 16 prevents protocol downgrade attacks on the Transport Layer Security 17 (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 3, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Protocol values . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 61 7.2. Informal References . . . . . . . . . . . . . . . . . . . 9 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 65 1. Introduction 67 To work around interoperability problems with legacy servers, many 68 TLS client implementations do not rely on the TLS protocol version 69 negotiation mechanism alone, but will intentionally reconnect using a 70 downgraded protocol if initial handshake attempts fail. Such clients 71 may fall back to connections in which they announce a version as low 72 as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest 73 supported version. 75 While such protocol downgrades can be a useful last resort for 76 connections to actual legacy servers, there's a risk that active 77 attackers could exploit the downgrade strategy to weaken the 78 cryptographic security of connections. Also, handshake errors due to 79 network glitches could similarly be misinterpreted as interaction 80 with a legacy server and result in a protocol downgrade. 82 All unnecessary protocol downgrades are undesirable (e.g., from TLS 83 1.2 to TLS 1.1 if both the client and the server actually do support 84 TLS 1.2); they can be particularly critical if they mean losing the 85 TLS extension feature (when downgrading to SSL 3.0). This document 86 defines a Signaling Cipher Suite Value (SCSV) that can be employed to 87 prevent unintended protocol downgrades between clients and servers 88 that comply to this document, by having the client indicate that the 89 current connection attempt is merely a fallback. 91 This specification applies to implementations of TLS 1.0 [RFC2246], 92 TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246]. (It is particularly 93 relevant if such implementations also include support for predecessor 94 protocol SSL 3.0 [RFC6101].) It can be applied similarly to later 95 protocol versions. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Protocol values 103 This document defines a new TLS cipher suite value: 105 TLS_FALLBACK_SCSV {0x56, 0x00} 107 This is a signaling cipher suite value (SCSV), i.e., it does not 108 actually correspond to a suite of cryptosystems, and it can never be 109 selected by the server in the handshake; rather, its presence in the 110 client hello message serves as a backwards-compatible signal from the 111 client to the server. 113 This document also allocates a new alert value in the TLS Alert 114 Registry [RFC5246]: 116 enum { 117 /* ... */ 118 inappropriate_fallback(86), 119 /* ... */ 120 (255) 121 } AlertDescription; 123 This alert is only generated by servers, as described in Section 3. 124 It is always fatal. 126 3. Server behavior 128 This section specifies server behavior when receiving the 129 TLS_FALLBACK_SCSV cipher suite from a client in 130 ClientHello.cipher_suites. 132 o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the 133 highest protocol version supported by the server is higher than 134 the version indicated in ClientHello.client_version, the server 135 MUST respond with an inappropriate_fallback alert. 137 Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears 138 and the client's protocol version is at least the highest protocol 139 version supported by the server), the server proceeds with the 140 handshake as usual. 142 4. Client behavior 144 The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients 145 that repeat a connection attempt with a downgraded protocol in order 146 to avoid interoperability problems with legacy servers. This section 147 specifies when to send it. 149 o If a client sends a ClientHello.client_version containing a lower 150 value than the latest (highest-valued) version supported by the 151 client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value 152 in ClientHello.cipher_suites. (Since the cipher suite list in the 153 ClientHello is ordered by preference, with the client's favorite 154 choice first, signaling cipher suite values will generally appear 155 after all cipher suites that the client actually intends to 156 negotiate.) 158 However, as an exception to the above, when the client intends to 159 perform an abbreviated handshake to resume a previously negotiated 160 session and sets ClientHello.client_version to the protocol 161 version negotiated for that session, the client MUST NOT include 162 TLS_FALLBACK_SCSV in ClientHello.cipher_suites. 164 Note that in the above, a protocol version is not considered 165 supported by the client if it has been disabled by any applicable 166 system or user settings: it is about the highest protocol version 167 that the client would attempt using in a handshake, not about the 168 highest protocol version implemented if its use is not actually 169 enabled. (For example, if the implementation supports TLS 1.2 but 170 the user has disabled this protocol version, a TLS 1.1 handshake is 171 expected and does not warrant sending TLS_FALLBACK_SCSV.) 173 5. Security Considerations 175 Section 4 does not require client implementations to send 176 TLS_FALLBACK_SCSV in any particular case, it merely recommends it; 177 behavior can be adapted according to the client's security needs. 178 For example, during the initial deployment of a new protocol version 179 (when some interoperability problems may have to be expected), 180 smoothly falling back to the previous protocol version in case of 181 problems may be preferrable to potentially not being able to connect 182 at all: so TLS_FALLBACK_SCSV could be omitted for this particular 183 protocol downgrade step. 185 However, it is strongly recommended to send TLS_FALLBACK_SCSV when 186 downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have 187 weaknesses that cannot be addressed by implementation workarounds 188 like the remaining weaknesses in later (TLS) protocol versions. 190 6. IANA Considerations 192 [[ NOTE IN DRAFT: The requested registry allocation requires 193 Standards Action, i.e., will only be official with the IESG's 194 Standards Track RFC approval. Since this document is currently an 195 Internet-Draft, IANA so far has in fact not added the cipher suite 196 number to the registry. ]] 198 IANA has added TLS cipher suite number 0x56,0x00 with name 199 TLS_FALLBACK_SCSV to the TLS Cipher Suite registry. 201 7. References 203 7.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997. 208 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 209 RFC 2246, January 1999. 211 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 212 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 214 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 215 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 217 7.2. Informal References 219 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 220 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 221 August 2011. 223 Appendix A. Acknowledgements 225 This specification was inspired by an earlier proposal by Eric 226 Rescorla. 228 Authors' Addresses 230 Bodo Moeller 231 Google Switzerland GmbH 232 Brandschenkestrasse 110 233 Zurich 8002 234 Switzerland 236 Email: bmoeller@acm.org 238 Adam Langley 239 Google Inc. 240 345 Spear St 241 San Francisco, CA 94105 242 USA 244 Email: agl@google.com