idnits 2.17.1 draft-bmoeller-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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC4346, 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 mention this, which it should. -- The draft header indicates that this document updates RFC2246, 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 28, 2013) is 3799 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 206, 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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,5246 Google 5 (if approved) November 28, 2013 6 Intended status: Standards Track 7 Expires: June 1, 2014 9 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol 10 Downgrade Attacks 11 draft-bmoeller-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. 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 June 1, 2014. 36 Copyright Notice 38 Copyright (c) 2013 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 60 6.2. Informal References . . . . . . . . . . . . . . . . . . . 8 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 1. Introduction 66 To work around interoperability problems with legacy servers, many 67 TLS client implementations do not rely on the TLS protocol version 68 negotiation mechanism alone, but will intentionally reconnect using a 69 downgraded protocol if initial handshake attempts fail. Such clients 70 may fall back to connections in which they announce a version as low 71 as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest 72 supported version. 74 While such protocol downgrades can be a useful last resort for 75 connections to actual legacy servers, there's a risk that active 76 attackers could exploit the downgrade strategy to weaken the 77 cryptographic security of connections. Also, handshake errors due to 78 network glitches could similary be misinterpreted as interaction with 79 a legacy server and result in a protocol downgrade. 81 All unnecessary protocol downgrades are undesirable (e.g., from TLS 82 1.2 to TLS 1.1 if both the client and the server actually do support 83 TLS 1.2); they can be particularly critical if they mean losing the 84 TLS extension feature (when downgrading to SSL 3.0). This document 85 defines a Signaling Cipher Suite Value (SCSV) that can be employed to 86 prevent unintended protocol downgrades between clients and servers 87 that comply to this document, by having the client indicate that the 88 current connection attempt is merely a fallback. 90 This specification applies to implementations of TLS 1.0 [RFC2246], 91 TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246]. (It is particularly 92 relevant if such implementations also include support for predecessor 93 protocol SSL 3.0 [RFC6101].) It can be applied similarly to later 94 protocol versions. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Protocol values 102 [[ NOTE IN DRAFT: The following registry allocations require 103 Standards Action, i.e. will only be official with the IESG's 104 Standards Track RFC approval. ]] 106 This document allocates a new cipher suite value in the TLS Cipher 107 Suite Registry [RFC5246]: 109 TLS_FALLBACK_SCSV {0x56, 0x00} 111 This is a signaling cipher suite value, i.e., it does not actually 112 correspond to a suite of cryptosystems, and it can never be selected 113 by the server in the handshake; rather, its presence in the client 114 hello message serves as a backwards-compatible signal from the client 115 to the server. 117 This document also allocates a new alert value in the TLS Alert 118 Registry [RFC5246]: 120 enum { 121 /* ... */ 122 inappropriate_fallback(86), 123 /* ... */ 124 (255) 125 } AlertDescription; 127 This alert is only generated by servers, as described in Section 3. 128 It is always fatal. 130 3. Server behavior 132 This section specifies server behavior when receiving the 133 TLS_FALLBACK_SCSV cipher suite from a client in 134 ClientHello.cipher_suites. 136 o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the 137 highest protocol version supported by the server is higher than 138 the version indicated in ClientHello.client_version, the server 139 MUST respond with a inappropriate_fallback alert. 141 Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears 142 and the client's protocol version is at least the highest protocol 143 version supported by the server), the server proceeds with the 144 handshake as usual. 146 4. Client behavior 148 The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients 149 that repeat a connection attempt with a downgraded protocol in order 150 to avoid interoperability problems with legacy servers. This section 151 specifies when to send it. 153 o If a client sends a ClientHello.client_version containing a lower 154 value than the latest (highest-valued) version supported by the 155 client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value 156 in ClientHello.cipher_suites. This does not apply when the client 157 intends to perform an abbreviated handshake to resume a previously 158 negotiated session and sets ClientHello.client_version to the 159 protocol version negotiated for that session. 161 Note that in the above, a protocol version is not considered 162 supported by the client if it has been disabled by any applicable 163 system or user settings: it is about the highest protocol version 164 that the client would attempt using in a handshake, not about the 165 highest protocol version implemented if its use is not actually 166 enabled. (For example, if the implementation supports TLS 1.2 but 167 the user has disabled this protocol version, a TLS 1.1 handshake is 168 expected and does not warrant sending TLS_FALLBACK_SCSV.) 170 5. Security Considerations 172 Section 4 does not require client implementations to send 173 TLS_FALLBACK_SCSV in any particular case, it merely recommends it; 174 behavior can be adapted according to the client's security needs. 175 For example, during the initial deployment of a new protocol version 176 (when some interoperability problems may have to be expected), 177 smoothly falling back to the previous protocol version in case of 178 problems may be preferrable to potentially not being able to connect 179 at all: so TLS_FALLBACK_SCSV could be omitted for this particular 180 protocol downgrade step. 182 However, it is particularly strongly recommended to send 183 TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher 184 suites in SSL 3.0 have weaknesses that cannot be addressed by 185 implementation workarounds like the remaining weaknesses in later 186 (TLS) protocol versions. 188 6. References 190 6.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, March 1997. 195 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 196 RFC 2246, January 1999. 198 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 199 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 201 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 202 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 204 6.2. Informal References 206 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 207 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 208 August 2011. 210 Appendix A. Acknowledgements 212 This specification was inspired by an earlier proposal by Eric 213 Rescorla. 215 Authors' Addresses 217 Bodo Moeller 218 Google Switzerland GmbH 219 Brandschenkestrasse 110 220 Zurich 8002 221 Switzerland 223 Email: bmoeller@acm.org 225 Adam Langley 226 Google Inc. 227 76 9th Ave 228 New York, NY 10011 229 USA 231 Email: agl@google.com