idnits 2.17.1 draft-thomson-sslv3-diediedie-00.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 (November 10, 2014) is 3449 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 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 (~~), 2 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: Best Current Practice A. Pironti 6 Expires: May 14, 2015 INRIA 7 A. Langley 8 Google 9 November 10, 2014 11 Deprecating Secure Sockets Layer Version 3.0 12 draft-thomson-sslv3-diediedie-00 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 May 14, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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. A Litany of Attacks . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Custom Cryptographic Primitives . . . . . . . . . . . . . 3 63 3. Limited Capabilities . . . . . . . . . . . . . . . . . . . . 3 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 6.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 The SSLv3 protocol has been subject to a long series of attacks, both 74 on its key exchange mechanism and on the encryption schemes it 75 supports since it was released in 1996. Despite being replaced by 76 TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] 77 and 1.2 in 2006 [RFC5246], availability of these replacement versions 78 has not been universal. As a result, many implementations of TLS 79 have permitted the negotiation of SSLv3. 81 The predecessor of SSLv3, SSL version 2, is no longer considered 82 secure [RFC6176]. SSLv3 now follows. 84 SSLv3 MUST NOT be used [RFC2119]. Negotiation of SSLv3 from any 85 version of TLS MUST NOT be permitted. 87 This document updates Appendix E of [RFC5246]. Clients MUST NOT set 88 a record layer version number (TLSPlaintext.version) of {03,00}. 89 Clients SHOULD offer their highest supported version (that is, the 90 same value that appears in ClientHello.client_version); though 91 clients MAY use any value greater than or equal to the lowest version 92 number they are willing to negotiate. Servers SHOULD accept 93 handshakes from clients that propose SSLv3 or higher, but MUST NOT 94 negotiate SSLv3. 96 2. A Litany of Attacks 98 2.1. Record Layer 100 The non-deterministic padding used in the CBC construction of SSLv3 101 trivially permits the recovery of plaintext [POODLE]. More 102 generally, the cipher block chaining (CBC) modes of SSLv3 use a 103 flawed MAC-then-encrypt construction that has subsequently been 104 replaced in TLS versions [RFC7366]. Unfortunately, the mechanism to 105 correct this flaw relies on extensions: a feature added in TLS 1.0. 106 SSLv3 cannot be updated to correct this flaw in the same way. 108 The flaws in the CBC modes in SSLv3 are mirrored by the weakness of 109 the stream ciphers it defines. Of those defined, only RC4 is 110 currently in widespread use. RC4, however, exhibits serious biases 111 and is also no longer fit for use [I-D.ietf-tls-prohibiting-rc4]. 113 This leaves SSLv3 with no suitable record protection mechanism. 115 2.2. Key Exchange 117 The SSLv3 key exchange is vulnerable to man-in-the-middle attacks 118 when renegotiation [Ray09] or session resumption [TRIPLE-HS] are 119 used. Each flaw has been fixed in TLS by means of extensions. 120 Again, SSLv3 cannot be updated to correct these flaws. 122 2.3. Custom Cryptographic Primitives 124 SSLv3 defines custom constructions for PRF, HMAC and digital 125 signature primitives. Such constructions lack the deep cryptographic 126 scrutiny that standard constructions used by TLS have received. 127 Furthermore, all SSLv3 primitives rely on SHA-1 [RFC3174] and MD5 128 [RFC1321]: these hash algorithms are considered weak and are being 129 systematically replaced with stronger hash functions, such as SHA-256 130 [FIPS180-2]. 132 3. Limited Capabilities 134 SSLv3 is unable to take advantage of the many features that have been 135 added to recent TLS versions. This includes the features that are 136 enabled by ClientHello extensions, which SSLv3 does not support. 138 Though SSLv3 can benefit from new cipher suites, it cannot benefit 139 from new cryptographic modes. Of these, the following are 140 particularly prominent: 142 o Authenticated Encryption with Additional Data (AEAD) modes are 143 added in [RFC5246]. 145 o Elliptic Curve Diffie-Hellman (ECDH) and Digital Signature 146 Algorithm (ECDSA) are added in [RFC4492]. 148 o Application layer protocol negotiation [RFC7301]. 150 o Stateless session tickets [RFC5077]. 152 o A datagram mode of operation, DTLS [RFC6347]. 154 4. IANA Considerations 156 This document has no IANA actions. 158 5. Security Considerations 160 This entire document aims to improve security by identifying a 161 protocol that is not secure. 163 6. References 165 6.1. Normative References 167 [I-D.ietf-tls-prohibiting-rc4] 168 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 169 tls-prohibiting-rc4-01 (work in progress), October 2014. 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, March 1997. 174 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 175 RFC 2246, January 1999. 177 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 178 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 180 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 181 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 182 for Transport Layer Security (TLS)", RFC 4492, May 2006. 184 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 185 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 187 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 188 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 189 August 2011. 191 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 192 Security (TLS) and Datagram Transport Layer Security 193 (DTLS)", RFC 7366, September 2014. 195 6.2. Informative References 197 [FIPS180-2] 198 Department of Commerce, National., "NIST FIPS 180-2, 199 Secure Hash Standard", August 2002. 201 [POODLE] Moeller, B., "This POODLE bites: exploiting the SSL 3.0 202 fallback", October 2014, 203 . 206 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 207 April 1992. 209 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 210 (SHA1)", RFC 3174, September 2001. 212 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 213 "Transport Layer Security (TLS) Session Resumption without 214 Server-Side State", RFC 5077, January 2008. 216 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 217 (SSL) Version 2.0", RFC 6176, March 2011. 219 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 220 Security Version 1.2", RFC 6347, January 2012. 222 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 223 "Transport Layer Security (TLS) Application-Layer Protocol 224 Negotiation Extension", RFC 7301, July 2014. 226 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009. 228 [TRIPLE-HS] 229 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 230 A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: 231 Breaking and Fixing Authentication over TLS", IEEE 232 Symposium on Security and Privacy, 2014. 234 Authors' Addresses 235 Richard Barnes 236 Mozilla 238 Email: rlb@ipv.sx 240 Martin Thomson 241 Mozilla 243 Email: martin.thomson@gmail.com 245 Alfredo Pironti 246 INRIA 248 Email: alfredo@pironti.eu 250 Adam Langley 251 Google 253 Email: agl@google.com