idnits 2.17.00 (12 Aug 2021) /tmp/idnits40611/draft-ietf-tls-downgrade-scsv-05.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 directly say this. It does mention RFC6347 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 (February 20, 2015) is 2640 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 (==), 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, 4347, 5246, 6347 Google 5 (if approved) February 20, 2015 6 Intended status: Standards Track 7 Expires: August 24, 2015 9 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol 10 Downgrade Attacks 11 draft-ietf-tls-downgrade-scsv-05 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) and Datagram Transport Layer Security (DTLS) protocols. It 18 updates RFC 2246, RFC 4346, RFC 4347, RFC 5246, and RFC 6347. Server 19 update considerations are included. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 24, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Protocol values . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 8.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 To work around interoperability problems with legacy servers, many 71 TLS client implementations do not rely on the TLS protocol version 72 negotiation mechanism alone, but will intentionally reconnect using a 73 downgraded protocol if initial handshake attempts fail. Such clients 74 may fall back to connections in which they announce a version as low 75 as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest 76 supported version. 78 While such fallback retries can be a useful last resort for 79 connections to actual legacy servers, there's a risk that active 80 attackers could exploit the downgrade strategy to weaken the 81 cryptographic security of connections. Also, handshake errors due to 82 network glitches could similarly be misinterpreted as interaction 83 with a legacy server and result in a protocol downgrade. 85 All unnecessary protocol downgrades are undesirable (e.g., from TLS 86 1.2 to TLS 1.1 if both the client and the server actually do support 87 TLS 1.2); they can be particularly harmful when the result is loss of 88 the TLS extension feature by downgrading to SSL 3.0. This document 89 defines a Signaling Cipher Suite Value (SCSV) that can be employed to 90 prevent unintended protocol downgrades between clients and servers 91 that comply with this document, by having the client indicate that 92 the current connection attempt is merely a fallback, and by having 93 the server return a fatal alert if it detects an inappropriate 94 fallback. (The alert does not necessarily indicate an intentional 95 downgrade attack, since network glitches too could result in 96 inappropriate fallback retries.) 97 The fallback SCSV defined in this document is not a suitable 98 substitute for proper TLS version negotiation. TLS implementations 99 need to properly handle TLS version negotiation and extensibility 100 mechanisms to avoid the security issues and connection delays 101 associated with fallback retries. 103 This specification applies to implementations of TLS 1.0 [RFC2246], 104 TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of 105 DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]. (It is particularly 106 relevant if the TLS implementations also include support for 107 predecessor protocol SSL 3.0 [RFC6101].) It can be applied similarly 108 to later protocol versions. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Protocol values 116 This document defines a new TLS cipher suite value: 118 TLS_FALLBACK_SCSV {0x56, 0x00} 120 This is a signaling cipher suite value (SCSV), i.e., it does not 121 actually correspond to a suite of cryptosystems, and it can never be 122 selected by the server in the handshake; rather, its presence in the 123 Client Hello message serves as a backwards-compatible signal from the 124 client to the server. 126 This document also allocates a new alert value in the TLS Alert 127 Registry [RFC5246]: 129 enum { 130 /* ... */ 131 inappropriate_fallback(86), 132 /* ... */ 133 (255) 134 } AlertDescription; 136 This alert is only generated by servers, as described in Section 3. 137 It is always fatal. 139 3. Server behavior 141 This section specifies server behavior when receiving the 142 TLS_FALLBACK_SCSV cipher suite from a client in 143 ClientHello.cipher_suites. 145 o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the 146 highest protocol version supported by the server is higher than 147 the version indicated in ClientHello.client_version, the server 148 MUST respond with a fatal inappropriate_fallback alert (unless it 149 responds with a fatal protocol_version alert because the version 150 indicated in ClientHello.client_version is unsupported). The 151 record layer version number for this alert MUST be set to either 152 ClientHello.client_version (as it would for the Server Hello 153 message if the server was continuing the handshake), or to the 154 record layer version number used by the client. 156 o Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears 157 and the client's protocol version is at least the highest protocol 158 version supported by the server), the server proceeds with the 159 handshake as usual. 161 (A protocol version is supported by the server if, in response to 162 appropriate Client Hello messages, the server would use it for 163 ServerHello.server_version. If a particular protocol version is 164 implemented but completely disabled by server settings, it is not 165 considered supported. For example, if the implementation's highest 166 protocol version is TLS 1.2 but the server operator has disabled this 167 version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV does not 168 warrant responding with an inappropriate_fallback alert.) 170 4. Client behavior 172 The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients 173 that repeat a connection attempt with a downgraded protocol (perform 174 a "fallback retry") in order to work around interoperability problems 175 with legacy servers. 177 o If a client sends a ClientHello.client_version containing a lower 178 value than the latest (highest-valued) version supported by the 179 client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value 180 in ClientHello.cipher_suites; see Section 6 for security 181 considerations for this recommendation. (The client SHOULD put 182 TLS_FALLBACK_SCSV after all cipher suites that it actually intends 183 to negotiate.) 185 o As an exception to the above, when a client intends to resume a 186 session and sets ClientHello.client_version to the protocol 187 version negotiated for that session, it MUST NOT include 188 TLS_FALLBACK_SCSV in ClientHello.cipher_suites. (In this case, it 189 is assumed that the client already knows the highest protocol 190 version supported by the server: see [RFC5246], Appendix E.1.) 192 o If a client sets ClientHello.client_version to its highest 193 supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV 194 in ClientHello.cipher_suites. 196 (A protocol version is supported by the client if the client normally 197 attempts to use it in handshakes. If a particular protocol version 198 is implemented but completely disabled by client settings, it is not 199 considered supported. For example, if the implementation's highest 200 protocol version is TLS 1.2 but the user has disabled this version, a 201 TLS 1.1 handshake is expected and does not warrant sending 202 TLS_FALLBACK_SCSV.) 204 Fallback retries could be caused by events such as network glitches, 205 and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites 206 may receive an inappropriate_fallback alert in response, indicating 207 that the server supports a higher protocol version. Thus, if a 208 client intends to use retries to work around network glitches, it 209 should then retry with the highest version it supports. 211 If a client keeps track of the highest protocol version apparently 212 supported by a particular server for use in 213 ClientHello.client_version later, then if the client receives an 214 inappropriate_fallback alert from that server, it MUST clear the 215 memorized highest supported protocol version. (Without the alert, it 216 is a good idea -- but outside of the scope of this document -- for 217 clients to clear that state after a time-out, since the server's 218 highest protocol version could change over time.) 220 For clients that use client-side TLS False Start [false-start], it is 221 important to note that the TLS_FALLBACK_SCSV mechanism cannot protect 222 the first round of application data sent by the client: refer to the 223 Security Considerations in [false-start], Section 6. 225 5. Operational Considerations 227 Updating legacy server clusters to simultaneously add support for 228 newer protocol versions and support for TLS_FALLBACK_SCSV can have 229 complications, if the legacy server implementation is not "version- 230 tolerant" (cannot properly handle Client Hello messages for newer 231 protocol versions): fallback retries required for interoperability 232 with old server nodes might be rejected by updated server nodes. 234 Updating the server cluster in two consecutive steps makes this safe: 235 first, update the server software but leave the highest supported 236 version unchanged (by disabling newer versions in server settings); 237 then, after all legacy (version-intolerant) implementations have been 238 removed, change server settings to allow new protocol versions. 240 6. Security Considerations 242 Section 4 does not require client implementations to send 243 TLS_FALLBACK_SCSV in any particular case, it merely recommends it; 244 behavior can be adapted according to the client's security needs. It 245 is important to remember that omitting TLS_FALLBACK_SCSV enables 246 downgrade attacks, so implementors must take into account whether the 247 protocol version given by ClientHello.client_version still provides 248 an acceptable level of protection. For example, during the initial 249 deployment of a new protocol version (when some interoperability 250 problems may have to be expected), smoothly falling back to the 251 previous protocol version in case of problems may be preferable to 252 potentially not being able to connect at all: so TLS_FALLBACK_SCSV 253 could be omitted for this particular protocol downgrade step. 255 However, it is strongly recommended to send TLS_FALLBACK_SCSV when 256 downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have 257 weaknesses that cannot be addressed by implementation workarounds 258 like the remaining weaknesses in later (TLS) protocol versions. 260 7. IANA Considerations 262 [[ TO BE REMOVED: The requested registry allocations require 263 Standards Action, i.e., will only be official with the IESG's 264 Standards Track RFC approval. Since this document is currently an 265 Internet-Draft, IANA so far has in fact not added the cipher suite 266 number and alert number to the respective registries. The values as 267 shown are used in early implementations. ]] 269 +-----------+-------------------+---------+-----------------+ 270 | Value | Description | DTLS-OK | Reference | 271 +-----------+-------------------+---------+-----------------+ 272 | 0x56,0x00 | TLS_FALLBACK_SCSV | Y | (this document) | 273 +-----------+-------------------+---------+-----------------+ 275 http://www.iana.org/assignments/tls-parameters 277 +-------+------------------------+---------+-----------------+ 278 | Value | Description | DTLS-OK | Reference | 279 +-------+------------------------+---------+-----------------+ 280 | 86 | inappropriate_fallback | Y | (this document) | 281 +-------+------------------------+---------+-----------------+ 283 http://www.iana.org/assignments/tls-parameters 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 330 Bodo Moeller 331 Google Switzerland GmbH 332 Brandschenkestrasse 110 333 Zurich 8002 334 Switzerland 336 Email: bmoeller@acm.org 338 Adam Langley 339 Google Inc. 340 345 Spear St 341 San Francisco, CA 94105 342 USA 344 Email: agl@google.com