idnits 2.17.00 (12 Aug 2021) /tmp/idnits16230/draft-ietf-tls-downgrade-scsv-04.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 (February 12, 2015) is 2654 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) February 12, 2015 6 Intended status: Standards Track 7 Expires: August 16, 2015 9 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol 10 Downgrade Attacks 11 draft-ietf-tls-downgrade-scsv-04 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. Server 18 update considerations are included. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 16, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Protocol values . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 To work around interoperability problems with legacy servers, many 70 TLS client implementations do not rely on the TLS protocol version 71 negotiation mechanism alone, but will intentionally reconnect using a 72 downgraded protocol if initial handshake attempts fail. Such clients 73 may fall back to connections in which they announce a version as low 74 as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest 75 supported version. 77 While such fallback retries can be a useful last resort for 78 connections to actual legacy servers, there's a risk that active 79 attackers could exploit the downgrade strategy to weaken the 80 cryptographic security of connections. Also, handshake errors due to 81 network glitches could similarly be misinterpreted as interaction 82 with a legacy server and result in a protocol downgrade. 84 All unnecessary protocol downgrades are undesirable (e.g., from TLS 85 1.2 to TLS 1.1 if both the client and the server actually do support 86 TLS 1.2); they can be particularly harmful when the result is loss of 87 the TLS extension feature by downgrading to SSL 3.0. This document 88 defines a Signaling Cipher Suite Value (SCSV) that can be employed to 89 prevent unintended protocol downgrades between clients and servers 90 that comply with this document, by having the client indicate that 91 the current connection attempt is merely a fallback, and by having 92 the server return a fatal alert if it detects an inappropriate 93 fallback. (The alert does not necessarily indicate an intentional 94 downgrade attack, since network glitches too could result in 95 inappropriate fallback retries.) 96 The fallback SCSV defined in this document is not a suitable 97 substitute for proper TLS version negotiation. TLS implementations 98 need to properly handle TLS version negotiation and extensibility 99 mechanisms to avoid the security issues and connection delays 100 associated with fallback retries. 102 This specification applies to implementations of TLS 1.0 [RFC2246], 103 TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of 104 DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]. (It is particularly 105 relevant if the TLS implementations also include support for 106 predecessor protocol SSL 3.0 [RFC6101].) It can be applied similarly 107 to later protocol versions. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Protocol values 115 This document defines a new TLS cipher suite value: 117 TLS_FALLBACK_SCSV {0x56, 0x00} 119 This is a signaling cipher suite value (SCSV), i.e., it does not 120 actually correspond to a suite of cryptosystems, and it can never be 121 selected by the server in the handshake; rather, its presence in the 122 Client Hello message serves as a backwards-compatible signal from the 123 client to the server. 125 This document also allocates a new alert value in the TLS Alert 126 Registry [RFC5246]: 128 enum { 129 /* ... */ 130 inappropriate_fallback(86), 131 /* ... */ 132 (255) 133 } AlertDescription; 135 This alert is only generated by servers, as described in Section 3. 136 It is always fatal. 138 3. Server behavior 140 This section specifies server behavior when receiving the 141 TLS_FALLBACK_SCSV cipher suite from a client in 142 ClientHello.cipher_suites. 144 o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the 145 highest protocol version supported by the server is higher than 146 the version indicated in ClientHello.client_version, the server 147 MUST respond with a fatal inappropriate_fallback alert (unless it 148 responds with a fatal protocol_version alert because the version 149 indicated in ClientHello.client_version is unsupported). The 150 record layer version number for this alert MUST be set to either 151 ClientHello.client_version (as it would for the Server Hello 152 message if the server was continuing the handshake), or to the 153 record layer version number used by the client. 155 o Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears 156 and the client's protocol version is at least the highest protocol 157 version supported by the server), the server proceeds with the 158 handshake as usual. 160 (A protocol version is supported by the server if, in response to 161 appropriate Client Hello messages, the server would use it for 162 ServerHello.server_version. If a particular protocol version is 163 implemented but completely disabled by server settings, it is not 164 considered supported. For example, if the implementation's highest 165 protocol version is TLS 1.2 but the server operator has disabled this 166 version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV does not 167 warrant responding with an inappropriate_fallback alert.) 169 4. Client behavior 171 The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients 172 that repeat a connection attempt with a downgraded protocol (perform 173 a "fallback retry") in order to work around interoperability problems 174 with legacy servers. 176 o If a client sends a ClientHello.client_version containing a lower 177 value than the latest (highest-valued) version supported by the 178 client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value 179 in ClientHello.cipher_suites; see Section 6 for security 180 considerations for this recommendation. (The client SHOULD put 181 TLS_FALLBACK_SCSV after all cipher suites that it actually intends 182 to negotiate.) 184 o As an exception to the above, when a client intends to resume a 185 session and sets ClientHello.client_version to the protocol 186 version negotiated for that session, it MUST NOT include 187 TLS_FALLBACK_SCSV in ClientHello.cipher_suites. (In this case, it 188 is assumed that the client already knows the highest protocol 189 version supported by the server: see [RFC5246], Appendix E.1.) 191 o If a client sets ClientHello.client_version to its highest 192 supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV 193 in ClientHello.cipher_suites. 195 (A protocol version is supported by the client if the client normally 196 attempts to use it in handshakes. If a particular protocol version 197 is implemented but completely disabled by client settings, it is not 198 considered supported. For example, if the implementation's highest 199 protocol version is TLS 1.2 but the user has disabled this version, a 200 TLS 1.1 handshake is expected and does not warrant sending 201 TLS_FALLBACK_SCSV.) 203 Fallback retries could be caused by events such as network glitches, 204 and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites 205 may receive an inappropriate_fallback alert in response, indicating 206 that the server supports a higher protocol version. Thus, if a 207 client intends to use retries to work around network glitches, it 208 should then retry with the highest version it supports. 210 If a client keeps track of the highest protocol version apparently 211 supported by a particular server for use in 212 ClientHello.client_version later, then if the client receives an 213 inappropriate_fallback alert from that server, it MUST clear the 214 memorized highest supported protocol version. (Without the alert, it 215 is a good idea -- but outside of the scope of this document -- for 216 clients to clear that state after a time-out, since the server's 217 highest protocol version could change over time.) 219 For clients that use client-side TLS False Start [false-start], it is 220 important to note that the TLS_FALLBACK_SCSV mechanism cannot protect 221 the first round of application data sent by the client: refer to the 222 Security Considerations in [false-start], Section 6. 224 5. Operational Considerations 226 Updating legacy server clusters to simultaneously add support for 227 newer protocol versions and support for TLS_FALLBACK_SCSV can have 228 complications, if the legacy server implementation is not "version- 229 tolerant" (cannot properly handle Client Hello messages for newer 230 protocol versions): fallback retries required for interoperability 231 with old server nodes might be rejected by updated server nodes. 233 Updating the server cluster in two consecutive steps makes this safe: 234 first, update the server software but leave the highest supported 235 version unchanged (by disabling newer versions in server settings); 236 then, after all legacy (version-intolerant) implementations have been 237 removed, change server settings to allow new protocol versions. 239 6. Security Considerations 241 Section 4 does not require client implementations to send 242 TLS_FALLBACK_SCSV in any particular case, it merely recommends it; 243 behavior can be adapted according to the client's security needs. It 244 is important to remember that omitting TLS_FALLBACK_SCSV enables 245 downgrade attacks, so implementors must take into account whether the 246 protocol version given by ClientHello.client_version still provides 247 an acceptable level of protection. For example, during the initial 248 deployment of a new protocol version (when some interoperability 249 problems may have to be expected), smoothly falling back to the 250 previous protocol version in case of problems may be preferable to 251 potentially not being able to connect at all: so TLS_FALLBACK_SCSV 252 could be omitted for this particular protocol downgrade step. 254 However, it is strongly recommended to send TLS_FALLBACK_SCSV when 255 downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have 256 weaknesses that cannot be addressed by implementation workarounds 257 like the remaining weaknesses in later (TLS) protocol versions. 259 7. IANA Considerations 261 [[ TO BE REMOVED: The requested registry allocations require 262 Standards Action, i.e., will only be official with the IESG's 263 Standards Track RFC approval. Since this document is currently an 264 Internet-Draft, IANA so far has in fact not added the cipher suite 265 number and alert number to the respective registries. The values as 266 shown are used in early implementations. 268 +-----------+-------------------+---------+-----------------+ 269 | Value | Description | DTLS-OK | Reference | 270 +-----------+-------------------+---------+-----------------+ 271 | 0x56,0x00 | TLS_FALLBACK_SCSV | Y | (this document) | 272 +-----------+-------------------+---------+-----------------+ 274 http://www.iana.org/assignments/tls-parameters 276 +-------+------------------------+---------+-----------------+ 277 | Value | Description | DTLS-OK | Reference | 278 +-------+------------------------+---------+-----------------+ 279 | 86 | inappropriate_fallback | Y | (this document) | 280 +-------+------------------------+---------+-----------------+ 282 http://www.iana.org/assignments/tls-parameters 284 ]] 285 IANA has added TLS cipher suite number 0x56,0x00 with name 286 TLS_FALLBACK_SCSV to the TLS Cipher Suite registry, and alert number 287 86 with name inappropriate_fallback to the TLS Alert registry. 289 8. References 291 8.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 297 RFC 2246, January 1999. 299 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 300 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 302 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 303 Security", RFC 4347, April 2006. 305 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 306 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 308 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 309 Security Version 1.2", RFC 6347, January 2012. 311 8.2. Informative References 313 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 314 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 315 August 2011. 317 [false-start] 318 Langley, A., Modadugu, N., and B. Moeller, "Transport 319 Layer Security (TLS) False Start", Work in Progress, 320 draft-bmoeller-tls-falsestart-01, November 2014. 322 Appendix A. Acknowledgements 324 This specification was inspired by an earlier proposal by Eric 325 Rescorla. We also thank Daniel Kahn Gillmor, Joe Saloway, Brian 326 Smith, Martin Thomson, and others in the TLS Working Group for their 327 feedback and suggestions. 329 Authors' Addresses 331 Bodo Moeller 332 Google Switzerland GmbH 333 Brandschenkestrasse 110 334 Zurich 8002 335 Switzerland 337 Email: bmoeller@acm.org 339 Adam Langley 340 Google Inc. 341 345 Spear St 342 San Francisco, CA 94105 343 USA 345 Email: agl@google.com