idnits 2.17.1 draft-pettersen-tls-version-rollback-removal-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3696 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Pettersen 3 Internet-Draft 4 Intended status: Informational February 13, 2014 5 Expires: August 17, 2014 7 Managing and removing automatic version rollback in TLS Clients 8 draft-pettersen-tls-version-rollback-removal-03 10 Abstract 12 Ever since vendors started deploying TLS 1.0 clients, these clients 13 have had to handle server implementations that do not tolerate the 14 TLS version supported by the client, usually by automatically 15 signaling an older supported version instead. Such version rollbacks 16 represent a potential security hazard, if the older version should 17 become vulnerable to attacks. The same history repeated when TLS 18 Extensions were introduced, as some servers would not negotiate with 19 clients that sent these protocol extensions, forcing clients to 20 reduce protocol functionality in order to maintain interoperability. 22 This document outlines a procedure to help clients decide when they 23 may use version rollback to maintain interoperability with legacy 24 servers, under what conditions the clients should not allow version 25 rollbacks, such as when the server has indicated support for the TLS 26 Renegotiation Information extension. The intention of this procedure 27 is to limit the use of automatic version rollback to legacy servers 28 and eventually eliminate its use. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 17, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 1. Introduction 64 When vendors of Transport Layer Security (TLS) clients intially 65 developed and released TLS 1.0 [RFC2246] clients, they quickly 66 discovered that not all Secure Sockets Layer (SSL) v3 [RFC6101] 67 servers were willing to accept or complete handshakes with the TLS 68 clients. The reasons for this varied across various server 69 implementations, such as not accepting versions higher than SSL v3, 70 and various errors in the implementation of the handshake, e.g., 71 expecting the RSA Premaster Secret's version field to match the 72 selected version, not the signaled version. 74 Given the scope of the problem of getting servers fixed, in order to 75 provide a good user experience for their customers, vendors elected 76 instead to restart the connection and signal the older protocol 77 version as the highest supported version in such cases. 79 This process was repeated when TLS Extensions[RFC6066], TLS 1.1 80 [RFC4346] and TLS 1.2 [RFC5246] were introduced, as clients had to 81 disable these features to be able to connect with servers that did 82 not tolerate them. 84 As a consequence, clients are not just vulnerable to a version 85 rollback attack; in the event that a vulnerability in older protocol 86 versions should be discovered, they are intentionally designed to be 87 vulnerable to such attacks by automatically performing a version 88 rollback whenever something goes wrong with the current TLS 89 handshake. 91 While it would be preferable that clients do not perform version 92 rollbacks, it is presently not practical to forbid it entirely, but 93 there are ways to limit the use of rollbacks, and eventually phase 94 out the usage completely. 96 This document presents a procedure for selecting when to allow a 97 version rollback and how to implement it, in order to maintain 98 interoperability with legacy servers, as well as when to not allow 99 version rollbacks. 101 The main factor for deciding not to allow version rollbacks is 102 whether the server supports the TLS Renegotiation Information 103 Extension[RFC5746]. [RFC5746] specifically reminds implementors that 104 servers MUST correctly handle clients that support TLS Extensions and 105 /or new TLS versions than supported by the server. For the most 106 part, server vendors have adhered to this, as (per July 2012) less 107 than 0.14% of servers with Renegotiation Information extension 108 support (70.6%) do not adhere to this requirement, compared to 4.5% 109 among servers that does not support this extension. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Managing Version Rollbacks 119 When a TLS client initially connects to a TLS server, it exchanges a 120 number messages with the server in order to establish the encrypted 121 connection: 123 o Sending the Client Hello, which identifies the client's higest 124 supported version, supported extensions, and cryptographic 125 parameters 127 o Receiving the Server Hello, which identifies the server's selected 128 version, supported extensions, cryptographic paramaters 130 o Exchange of more messages to negotiate the encryption keys, and 131 other parameters 133 o Each sends a Finished message to the other, showing that the 134 negotiation succeeded, after which the secure connection is active 136 Each step of this negotiation sequence can fail for various reasons, 137 until the Finished messages have been sent and verified. The 138 failures can be indicated with Alert codes or by just shutting down 139 the connection. Frequently, many of these failures are due to 140 incorrect implementation on either end. 142 This tendency toward implementation issues leading to connection 143 failures have caused most client vendors to adopt a policy of 144 retrying with older versions of the protocol, in case the failure was 145 caused by version-specific problems in the server. 147 2.1. Version Rollback Sequence 149 When establishing a TLS connection to a server with unknown 150 capabilities, a client SHOULD use the following sequence, advancing 151 to the next step if the connection attempt fails. 153 1. If the client supports TLS 1.1 or higher, it SHOULD send a Client 154 Hello indicating this highest version and include all supported 155 extensions. The version of the Record Protocol SHOULD at most be 156 TLS 1.0 158 2. If step 1 failed, and the server either did not indicate a 159 supported version or this version was TLS 1.0 or below, send a 160 Client Hello indicating TLS 1.0 as the highest version and 161 include all supported extensions. If this fails, the client MAY 162 remove extensions in a separate connection attempt before 163 considering this step to have failed. 165 3. If step 2 failed, and the server either did not indicate a 166 supported version or this version was SSL v3, send a Client Hello 167 indicating SSL v3 as the highest version, without sending TLS 168 Extensions. 170 In each step, the client MUST indicate support for the TLS 171 Renegotiation Information Extension, using the 172 TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite value specified by 173 [RFC5746] if TLS Extensions are not sent in the Client Hello. 175 The client MUST NOT roll back to an older version than the server has 176 indicated, even if the connection handshake failed. That is, if the 177 server indicates support for TLS 1.1, but the connection fails, then 178 the client MUST NOT attempt to connect to the server using TLS 1.0, 179 but allow the connection to fail. 181 2.2. Version Recovery 183 Once a connection is established and the client has received the 184 Server Hello, it MUST check the response to determine if the server 185 sends the TLS Renegotiation Information (RI) extension, and then 186 decide how to proceed: 188 o If the server did not return the RI extension, the client can 189 continue the handshake as normal and MAY continue version 190 rollbacks as described in Section 2.1 if the connection fails. 192 o If the server did return the RI extension, and the client 193 indicated its highest supported version, with extensions, (first 194 step in Section 2.1) in the Client Hello, the client can continue 195 the handshake as normal but MUST NOT permit version rollbacks, in 196 case the connection fails, but instead allow the connection to 197 fail. 199 o If the server did return the RI extension, but the client was 200 indicating an older TLS version as its highest supported version, 201 or without TLS Extensions, the client MUST terminate the 202 connection, reestablish it, and send a Client Hello that signals 203 the highest supported version, and includes extensions, and it 204 MUST NOT permit a failure to trigger a new version rollback 205 sequence, but instead end the attempt to establish the connection. 207 The reason for not allowing version rollbacks if the server supports 208 the RI extension is that such servers MUST accept that clients 209 indicate a higher supported version than they do, and they MUST 210 support or tolerate clients that send TLS Extensions. It must be 211 presumed that, if such a handshake fails, it is because the 212 connection is being subjected to a active version downgrade attack, 213 not that the server has been incorrectly implemented in this respect. 215 3. IANA Considerations 217 This document makes no request of IANA. 219 Note to RFC Editor: this section may be removed on publication as an 220 RFC. 222 4. Security Considerations 224 Allowing automatic version rollbacks exposes the TLS connection 225 between the client and server to significant risk if the older 226 version that gets negotiated is vulnerable to an attack that allows 227 the transmitted information to leak. 229 The use of automatic version rollbacks should be limited to 230 connections to servers that require it for interoperability reasons 231 and be prohibited for any other servers. While it is impractial to 232 discover which servers truly need such consideration, this document 233 specifies the presence of the TLS Renegotiation Information extension 234 as a proxy indication that the server does not require such 235 interoperability considerations. 237 5. Acknowledgements 239 6. References 241 6.1. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 247 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 249 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 250 "Transport Layer Security (TLS) Renegotiation Indication 251 Extension", RFC 5746, February 2010. 253 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 254 Extension Definitions", RFC 6066, January 2011. 256 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 257 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 258 August 2011. 260 6.2. Informative References 262 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 263 RFC 2246, January 1999. 265 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 266 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 268 Author's Address 270 Yngve N. Pettersen 272 Email: yngve@spec-work.net