idnits 2.17.1 draft-ietf-tls-downgrade-scsv-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 draft header indicates that this document updates RFC6347, 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 directly say this. It does mention RFC5246 though, so this could be OK. -- The draft header indicates that this document updates RFC4347, 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 (November 10, 2014) is 3448 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) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 6 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, 4347, 5246, 6347 Google 5 (if approved) November 10, 2014 6 Intended status: Standards Track 7 Expires: May 14, 2015 9 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol 10 Downgrade Attacks 11 draft-ietf-tls-downgrade-scsv-01 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 May 14, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Protocol values . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 8.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 To work around interoperability problems with legacy servers, many 69 TLS client implementations do not rely on the TLS protocol version 70 negotiation mechanism alone, but will intentionally reconnect using a 71 downgraded protocol if initial handshake attempts fail. Such clients 72 may fall back to connections in which they announce a version as low 73 as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest 74 supported version. 76 While such fallback retries can be a useful last resort for 77 connections to actual legacy servers, there's a risk that active 78 attackers could exploit the downgrade strategy to weaken the 79 cryptographic security of connections. Also, handshake errors due to 80 network glitches could similarly be misinterpreted as interaction 81 with a legacy server and result in a protocol downgrade. 83 All unnecessary protocol downgrades are undesirable (e.g., from TLS 84 1.2 to TLS 1.1 if both the client and the server actually do support 85 TLS 1.2); they can be particularly critical if they mean losing the 86 TLS extension feature (when downgrading to SSL 3.0). This document 87 defines a Signaling Cipher Suite Value (SCSV) that can be employed to 88 prevent unintended protocol downgrades between clients and servers 89 that comply with this document, by having the client indicate that 90 the current connection attempt is merely a fallback, and by having 91 the server return a fatal alert if it detects an inappropriate 92 fallback. (The alert does not necessarily indicate an intentional 93 downgrade attack, since network glitches too could result in 94 inappropriate fallback retries.) 95 The fallback SCSV defined in this document is not suitable substitute 96 for proper TLS version negotiation. TLS implementations need to 97 properly handle TLS version negotiation and extensibility mechanisms 98 to avoid the security issues and connection delays associated with 99 fallback retries." 101 This specification applies to implementations of TLS 1.0 [RFC2246], 102 TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of 103 DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]. (It is particularly 104 relevant if TLS implementations also include support for predecessor 105 protocol SSL 3.0 [RFC6101].) It can be applied similarly to later 106 protocol versions. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Protocol values 114 This document defines a new TLS cipher suite value: 116 TLS_FALLBACK_SCSV {0x56, 0x00} 118 This is a signaling cipher suite value (SCSV), i.e., it does not 119 actually correspond to a suite of cryptosystems, and it can never be 120 selected by the server in the handshake; rather, its presence in the 121 Client Hello message serves as a backwards-compatible signal from the 122 client to the server. 124 This document also allocates a new alert value in the TLS Alert 125 Registry [RFC5246]: 127 enum { 128 /* ... */ 129 inappropriate_fallback(86), 130 /* ... */ 131 (255) 132 } AlertDescription; 134 This alert is only generated by servers, as described in Section 3. 135 It is always fatal. 137 3. Server behavior 139 This section specifies server behavior when receiving the 140 TLS_FALLBACK_SCSV cipher suite from a client in 141 ClientHello.cipher_suites. 143 o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the 144 highest protocol version supported by the server is higher than 145 the version indicated in ClientHello.client_version, the server 146 MUST respond with a fatal inappropriate_fallback alert. 148 o Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears 149 and the client's protocol version is at least the highest protocol 150 version supported by the server), the server proceeds with the 151 handshake as usual. 153 (A protocol version is supported by the server if, in response to 154 appropriate Client Hello messages, the server would use it for 155 ServerHello.server_version. If a particular protocol version is 156 implemented but completely disabled by server settings, it is not 157 considered supported. For example, if the implementation's highest 158 protocol version is TLS 1.2 but the server operator has disabled this 159 version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV does not 160 warrant responding with an inappropriate_fallback alert.) 162 4. Client behavior 164 The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients 165 that repeat a connection attempt with a downgraded protocol (perform 166 a "fallback retry") in order to work around interoperability problems 167 with legacy servers. 169 o If a client sends a ClientHello.client_version containing a lower 170 value than the latest (highest-valued) version supported by the 171 client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value 172 in ClientHello.cipher_suites; see Section 6 for security 173 considerations for this recommendation. (Since the cipher suite 174 list in the ClientHello is ordered by preference, with the 175 client's favorite choice first, signaling cipher suite values will 176 generally appear after all cipher suites that the client actually 177 intends to negotiate.) 179 o As an exception to the above, when a client intends to resume a 180 session and sets ClientHello.client_version to the protocol 181 version negotiated for that session, it MUST NOT include 182 TLS_FALLBACK_SCSV in ClientHello.cipher_suites. (In this case, it 183 is assumed that the client already knows the highest protocol 184 version supported by the server: see [RFC5246], Appendix E.1.) 186 o If a client sets ClientHello.client_version to its highest 187 supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV 188 in ClientHello.cipher_suites. 190 (A protocol version is supported by the client if the client normally 191 attempts to use it in handshakes. If a particular protocol version 192 is implemented but completely disabled by client settings, it is not 193 considered supported. For example, if the implementation's highest 194 protocol version is TLS 1.2 but the user has disabled this version, a 195 TLS 1.1 handshake is expected and does not warrant sending 196 TLS_FALLBACK_SCSV.) 198 Fallback retries could be caused by events such as network glitches, 199 and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites 200 may receive an inappropriate_fallback alert in response, indicating 201 that the server supports a higher protocol version. Thus, if a 202 client intends to use retries to work around network glitches, it 203 should then retry with the highest version it supports. 205 If a client keeps track of the highest protocol version apparently 206 supported by a particular server for use in 207 ClientHello.client_version later, then if the client receives an 208 inappropriate_fallback alert from that server, it MUST clear the 209 memorized highest supported protocol version. (Without the alert, it 210 is a good idea -- but outside of the scope of this document -- for 211 clients to clear that state after a time-out, since the server's 212 highest protocol version could change over time.) 214 For clients that use client-side TLS False Start [false-start], it is 215 important to note that the TLS_FALLBACK_SCSV mechanism cannot protect 216 the first round of application data sent by the client: refer to the 217 Security Considerations in [false-start], Section 6. 219 5. Operational Considerations 221 Updating legacy server clusters to simultaneously add support for 222 newer protocol versions and support for TLS_FALLBACK_SCSV can have 223 complications, if the legacy server implementation is not "version- 224 tolerant" (cannot properly handle Client Hello messages for newer 225 protocol versions): fallback retries required for interoperability 226 with old server nodes might be rejected by updated server nodes. 228 Updating the server cluster in two consecutive steps makes this safe: 229 first, update the server software but leave the highest supported 230 version unchanged (by disabling newer versions in server settings); 231 then, after all legacy (version-intolerant) implementations have been 232 removed, change server settings to allow new protocol versions. 234 6. Security Considerations 236 Section 4 does not require client implementations to send 237 TLS_FALLBACK_SCSV in any particular case, it merely recommends it; 238 behavior can be adapted according to the client's security needs. It 239 is important to remember that omitting TLS_FALLBACK_SCSV enables 240 downgrade attacks, so implementors must take into account whether the 241 protocol version given by ClientHello.client_version still provides 242 an acceptable level of protection. For example, during the initial 243 deployment of a new protocol version (when some interoperability 244 problems may have to be expected), smoothly falling back to the 245 previous protocol version in case of problems may be preferable to 246 potentially not being able to connect at all: so TLS_FALLBACK_SCSV 247 could be omitted for this particular protocol downgrade step. 249 However, it is strongly recommended to send TLS_FALLBACK_SCSV when 250 downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have 251 weaknesses that cannot be addressed by implementation workarounds 252 like the remaining weaknesses in later (TLS) protocol versions. 254 7. IANA Considerations 256 [[ TO BE REMOVED: The requested registry allocations require 257 Standards Action, i.e., will only be official with the IESG's 258 Standards Track RFC approval. Since this document is currently an 259 Internet-Draft, IANA so far has in fact not added the cipher suite 260 number and alert number to the respective registries. The values as 261 shown are used in early implementations. 263 +-----------+-------------------+---------+-----------------+ 264 | Value | Description | DTLS-OK | Reference | 265 +-----------+-------------------+---------+-----------------+ 266 | 0x56,0x00 | TLS_FALLBACK_SCSV | Y | (this document) | 267 +-----------+-------------------+---------+-----------------+ 269 http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml 270 #tls-parameters-4 272 +-------+------------------------+---------+-----------------+ 273 | Value | Description | DTLS-OK | Reference | 274 +-------+------------------------+---------+-----------------+ 275 | 86 | inappropriate_fallback | Y | (this document) | 276 +-------+------------------------+---------+-----------------+ 278 http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml 279 #tls-parameters-6 281 ]] 282 IANA has added TLS cipher suite number 0x56,0x00 with name 283 TLS_FALLBACK_SCSV to the TLS Cipher Suite registry, and alert number 284 86 with name inappropriate_fallback to the TLS Alert registry. 286 8. References 288 8.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 294 RFC 2246, January 1999. 296 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 297 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 299 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 300 Security", RFC 4347, April 2006. 302 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 303 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 305 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 306 Security Version 1.2", RFC 6347, January 2012. 308 8.2. Informative References 310 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 311 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 312 August 2011. 314 [false-start] 315 Langley, A., Modadugu, N., and B. Moeller, "Transport 316 Layer Security (TLS) False Start", Work in Progress, 317 draft-bmoeller-tls-falsestart-01, November 2014. 319 Appendix A. Acknowledgements 321 This specification was inspired by an earlier proposal by Eric 322 Rescorla. We also thank Daniel Kahn Gillmor, Joe Saloway, Brian 323 Smith, Martin Thomson, and others in the TLS Working Group for their 324 feedback and suggestions. 326 Authors' Addresses 328 Bodo Moeller 329 Google Switzerland GmbH 330 Brandschenkestrasse 110 331 Zurich 8002 332 Switzerland 334 Email: bmoeller@acm.org 336 Adam Langley 337 Google Inc. 338 345 Spear St 339 San Francisco, CA 94105 340 USA 342 Email: agl@google.com