idnits 2.17.00 (12 Aug 2021) /tmp/idnits20819/draft-ietf-tls-sslv3-diediedie-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 abstract seems to contain references ([RFC5246], [RFC6101]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5246, updated by this document, for RFC5378 checks: 2006-03-02) -- 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 (March 1, 2015) is 2637 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-tls-prohibiting-rc4 has been published as RFC 7465 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Historic RFC: RFC 6101 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft M. Thomson 4 Updates: 5246 (if approved) Mozilla 5 Intended status: Standards Track A. Pironti 6 Expires: September 2, 2015 INRIA 7 A. Langley 8 Google 9 March 1, 2015 11 Deprecating Secure Sockets Layer Version 3.0 12 draft-ietf-tls-sslv3-diediedie-01 14 Abstract 16 Secure Sockets Layer version 3.0 (SSLv3) [RFC6101] is no longer 17 secure. This document requires that SSLv3 not be used. The 18 replacement versions, in particular Transport Layer Security (TLS) 19 1.2 [RFC5246], are considerably more secure and capable protocols. 21 This document updates the backward compatibility sections of the TLS 22 RFCs to prohibit fallback to SSLv3. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 2, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Do Not Use SSL Version 3.0 . . . . . . . . . . . . . . . . . 2 60 3. A Litany of Attacks . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 3 63 3.3. Custom Cryptographic Primitives . . . . . . . . . . . . . 3 64 4. Limited Capabilities . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 7.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The SSLv3 protocol has been subject to a long series of attacks, both 75 on its key exchange mechanism and on the encryption schemes it 76 supports since it was released in 1996. Despite being replaced by 77 TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] 78 and 1.2 in 2006 [RFC5246], availability of these replacement versions 79 has not been universal. As a result, many implementations of TLS 80 have permitted the negotiation of SSLv3. 82 The predecessor of SSLv3, SSL version 2, is no longer considered 83 secure [RFC6176]. SSLv3 now follows. 85 2. Do Not Use SSL Version 3.0 87 SSLv3 MUST NOT be used [RFC2119]. Negotiation of SSLv3 from any 88 version of TLS MUST NOT be permitted. 90 Any version of TLS is more secure than SSLv3, though the highest 91 version available is preferable. 93 Pragmatically, clients MUST NOT send a ClientHello with 94 ClientHello.client_version set to {03,00}. Similarly, servers MUST 95 NOT send a ServerHello with ServerHello.server_version set to 96 {03,00}. Any party receiving a Hello message with the protocol 97 version set to {03,00} MUST respond with a "protocol_version" alert 98 message and close the connection. 100 Historically, TLS specifications were not clear on what the record 101 layer version number (TLSPlaintext.version) could contain when 102 sending ClientHello. Appendix E of [RFC5246] notes that 103 TLSPlaintext.version could be selected to maximize interoperability, 104 though no definitive value is identified as ideal. That guidance is 105 still applicable; therefore, TLS servers MUST accept any value 106 {03,XX} (including {03,00}) as the record layer version number for 107 ClientHello, but they MUST NOT negotiate SSLv3. 109 3. A Litany of Attacks 111 3.1. Record Layer 113 The non-deterministic padding used in the CBC construction of SSLv3 114 trivially permits the recovery of plaintext [POODLE]. More 115 generally, the cipher block chaining (CBC) modes of SSLv3 use a 116 flawed MAC-then-encrypt construction that has subsequently been 117 replaced in TLS versions [RFC7366]. Unfortunately, the mechanism to 118 correct this flaw relies on extensions: a feature added in TLS 1.0. 119 SSLv3 cannot be updated to correct this flaw in the same way. 121 The flaws in the CBC modes in SSLv3 are mirrored by the weakness of 122 the stream ciphers it defines. Of those defined, only RC4 is 123 currently in widespread use. RC4, however, exhibits serious biases 124 and is also no longer fit for use [I-D.ietf-tls-prohibiting-rc4]. 126 This leaves SSLv3 with no suitable record protection mechanism. 128 3.2. Key Exchange 130 The SSLv3 key exchange is vulnerable to man-in-the-middle attacks 131 when renegotiation [Ray09] or session resumption [TRIPLE-HS] are 132 used. Each flaw has been fixed in TLS by means of extensions. 133 Again, SSLv3 cannot be updated to correct these flaws. 135 3.3. Custom Cryptographic Primitives 137 SSLv3 defines custom constructions for PRF, HMAC and digital 138 signature primitives. Such constructions lack the deep cryptographic 139 scrutiny that standard constructions used by TLS have received. 140 Furthermore, all SSLv3 primitives rely on SHA-1 [RFC3174] and MD5 141 [RFC1321]: these hash algorithms are considered weak and are being 142 systematically replaced with stronger hash functions, such as SHA-256 143 [FIPS180-2]. 145 4. Limited Capabilities 147 SSLv3 is unable to take advantage of the many features that have been 148 added to recent TLS versions. This includes the features that are 149 enabled by ClientHello extensions, which SSLv3 does not support. 151 Though SSLv3 can benefit from new cipher suites, it cannot benefit 152 from new cryptographic modes and features. Of these, the following 153 are particularly prominent: 155 o Authenticated Encryption with Additional Data (AEAD) modes are 156 added in [RFC5246]. 158 o Elliptic Curve Diffie-Hellman (ECDH) and Digital Signature 159 Algorithm (ECDSA) are added in [RFC4492]. 161 o Stateless session tickets [RFC5077]. 163 o A datagram mode of operation, DTLS [RFC6347]. 165 o Application layer protocol negotiation [RFC7301]. 167 5. IANA Considerations 169 This document has no IANA actions. 171 6. Security Considerations 173 This entire document aims to improve security by prohibiting the use 174 of a protocol that is not secure. 176 7. References 178 7.1. Normative References 180 [I-D.ietf-tls-prohibiting-rc4] 181 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 182 tls-prohibiting-rc4-01 (work in progress), October 2014. 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 188 RFC 2246, January 1999. 190 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 191 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 193 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 194 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 195 for Transport Layer Security (TLS)", RFC 4492, May 2006. 197 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 198 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 200 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 201 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 202 August 2011. 204 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 205 Security (TLS) and Datagram Transport Layer Security 206 (DTLS)", RFC 7366, September 2014. 208 7.2. Informative References 210 [FIPS180-2] 211 Department of Commerce, National., "NIST FIPS 180-2, 212 Secure Hash Standard", August 2002. 214 [POODLE] Moeller, B., "This POODLE bites: exploiting the SSL 3.0 215 fallback", October 2014, 216 . 219 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 220 April 1992. 222 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 223 (SHA1)", RFC 3174, September 2001. 225 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 226 "Transport Layer Security (TLS) Session Resumption without 227 Server-Side State", RFC 5077, January 2008. 229 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 230 (SSL) Version 2.0", RFC 6176, March 2011. 232 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 233 Security Version 1.2", RFC 6347, January 2012. 235 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 236 "Transport Layer Security (TLS) Application-Layer Protocol 237 Negotiation Extension", RFC 7301, July 2014. 239 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009. 241 [TRIPLE-HS] 242 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 243 A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: 244 Breaking and Fixing Authentication over TLS", IEEE 245 Symposium on Security and Privacy, 2014. 247 Authors' Addresses 249 Richard Barnes 250 Mozilla 252 Email: rlb@ipv.sx 254 Martin Thomson 255 Mozilla 257 Email: martin.thomson@gmail.com 259 Alfredo Pironti 260 INRIA 262 Email: alfredo@pironti.eu 264 Adam Langley 265 Google 267 Email: agl@google.com