idnits 2.17.1 draft-sheffer-tls-bcp-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 8, 2013) is 3882 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 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-02) exists of draft-popov-tls-prohibiting-rc4-00 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: BCP September 8, 2013 5 Expires: March 12, 2014 7 Recommendations for Secure Use of TLS and DTLS 8 draft-sheffer-tls-bcp-00 10 Abstract 12 Over the last few years there have been several serious attacks on 13 TLS, including attacks on its most commonly used ciphers and modes of 14 operation. This document offers recommendations on securely using 15 the TLS and DTLS protocols, given existing standards and 16 implementations. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 12, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions used in this document . . . . . . . . . . . 3 54 2. Attacks on TLS . . . . . . . . . . . . . . . . . . . . 3 55 2.1. BEAST . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Lucky Thirteen . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . 4 58 2.4. Compression Attacks: CRIME and BREACH . . . . . . . . . 4 59 3. Selection Criteria . . . . . . . . . . . . . . . . . . 4 60 4. Recommendations . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Details . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Implementation Status . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . 6 64 6.1. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . 7 70 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 8 71 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Over the last few years there have been several major attacks on TLS 77 [RFC5246], including attacks on its most commonly used ciphers and 78 modes of operation. Details are given in Section 2, but suffice it 79 to say that both AES-CBC and RC4, which together make up for most 80 current usage, have been seriously attacked in the context of TLS. 82 Given these issues, there is need for IETF guidance on how TLS can be 83 used securely. Unlike most IETF documents, this is guidance for 84 deployers rather than for implementers. In fact the recommendations 85 below call for the use of widely implemented algorithms, which are 86 not seeing widespread use today. 88 This recommendation applies to both TLS and DTLS. TLS 1.3, when it 89 is standardized and deployed in the field, should resolve the current 90 vulnerabilities while providing significantly better functionality, 91 and will very likely obsolete the current document. 93 1.1. Conventions used in this document 95 [[Are we normative? This section might go away.]] 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Attacks on TLS 103 This section lists the attacks that motivated the current 104 recommendation. This is not intended to be an extensive survey of 105 TLS's security. 107 While there are widely deployed mitigations for some of the attacks 108 listed below, we believe that their root causes necessitate a more 109 systemic solution. 111 2.1. BEAST 113 The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation 114 of CBC (that is, predictable IV) to decrypt parts of a packet, and 115 specifically shows how this can be used to decrypt HTTP cookies when 116 run over TLS. 118 2.2. Lucky Thirteen 120 A consequence of the MAC-then-encrypt design is the existence of 121 padding oracle attacks [Padding-Oracle]. A recent incarnation of 122 these attacks is the Lucky Thirteen attack [CBC-Attack], a timing 123 side-channel attack that allows the attacker to decrypt arbitrary 124 ciphertext. 126 2.3. Attacks on RC4 128 The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) 129 for many years. Attacks have also been known for a long time, e.g. 130 [RC4-Attack-FMS]. But recent attacks [RC4-Attack] have weakened this 131 algorithm even more. See [I-D.popov-tls-prohibiting-rc4] for more 132 details. 134 2.4. Compression Attacks: CRIME and BREACH 136 The CRIME attack [CRIME] allows an active attacker to decrypt 137 cyphertext (specifically, cookies) when TLS is used with protocol- 138 level compression. The attack is a consequence of the TLS MAC-then- 139 encrypt approach. 141 The BREACH attack [BREACH] makes similar use of HTTP-level 142 compression which is much more prevalent than compression at the TLS 143 level, to decrypt secret data passed in the HTTP response. 145 While the former attack can be mitigated by disabling TLS 146 compression, we are not aware of mitigations at the protocol level to 147 the latter attack, and so application-level mitigations are needed. 148 For example, implementations of HTTP that use CSRF tokens will need 149 to randomize them even when the recommendations of the current 150 document are adopted. 152 [[Is it possible to affect some length hiding using TLS 1.2 as 153 specified today, i.e. without draft-pironti-tls-length-hiding-01, and 154 using available APIs?]] 156 3. Selection Criteria 158 Given the above attacks, we are proposing that deployers opt for a 159 specific ciphersuite when negotiating TLS. We have used the 160 following criteria when framing our recommendations: 162 o The ciphersuite must be secure in default use, and should not 163 require any additional security measures beyond those defined in 164 the standard. 166 o The ciphersuite must be widely implemented, i.e. available in a 167 large percentage of popular cryptographic libraries. 168 o The ciphersuite must have undergone a significant amount of 169 analysis, and the algorithm and mode of operation must both be 170 standardized by relevant organizations. 171 o We prefer ciphersuites that provide client-side privacy and 172 perfect forward secrecy, i.e. those that use ephemeral Diffie- 173 Hellman. 174 o When there are multiple key sizes available, we have chosen the 175 current industry standard, 128 bits of strength. Of course 176 deployers are free to opt for a stronger ciphersuite. 178 4. Recommendations 180 Based on the criteria above, we recommend using as a preferred 181 ciphersuite the following: 183 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] 185 It is noted that the above ciphersuite is an authenticated encryption 186 (AEAD) algorithm [RFC5116], and therefore requires the use of TLS 187 1.2. 189 4.1. Details 191 We recommend that clients include this cipher suite as the first 192 proposal to any server, unless they have prior knowledge that the 193 server cannot respond to a TLS 1.2 client_hello message. 195 We recommend that servers prefer this ciphersuite (or a similar but 196 stronger one) whenever it is proposed, even if it is not the first 197 proposal. 199 Note that other profiles of TLS 1.2 exist that use different 200 ciphersuites. For example, [RFC6460] defines a profile that uses the 201 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 202 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuites. 204 5. Implementation Status 206 Since this document does not propose a new protocol or a new 207 ciphersuite, we do not provide a full implementation status, as per 208 [RFC6982]. However it is useful to list some known existing 209 implementations of the recommended ciphersuite(s). 211 +----------+----------------+--------------+------------------------+ 212 | Category | Software | As Of | Comment | 213 | | | Version | | 214 +----------+----------------+--------------+------------------------+ 215 | Library | OpenSSL | 1.0.1 | | 216 | | GnuTLS | | | 217 | | NSS | 3.11.1 | | 218 | Browser | Internet | IE8 on | | 219 | | Explorer | Windows 7 | | 220 | | Firefox | | TBD | 221 | | Chrome | | TBD | 222 | | Safari | | TBD | 223 | Web | Apache | ?? | | 224 | server | (mod_gnutls) | | | 225 | | Apache | ?? | | 226 | | (mod_ssl) | | | 227 | | Nginx | 1.0.9, 1.1.6 | With a recent version | 228 | | | | of OpenSSL | 229 +----------+----------------+--------------+------------------------+ 231 6. Security Considerations 233 6.1. AES-GCM 235 Please refer to [RFC5246], Sec. 11 for general security 236 considerations when using TLS 1.2, and to [RFC5288], Sec. 6 for 237 security considerations that apply specifically to AES-GCM when used 238 with TLS. 240 6.2. Downgrade Attacks 242 [[Do we need to disallow some protocol variants, e.g. SSL 3.0, so 243 that there are no downgrade attacks possible?]] 245 7. IANA Considerations 247 This document requires no IANA actions. 249 8. References 251 8.1. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 257 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 259 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 260 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 261 August 2008. 263 8.2. Informative References 265 [I-D.popov-tls-prohibiting-rc4] 266 Popov, A., "Prohibiting RC4 Cipher Suites", 267 draft-popov-tls-prohibiting-rc4-00 (work in progress), 268 August 2013. 270 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 271 Encryption", RFC 5116, January 2008. 273 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 274 Layer Security (TLS)", RFC 6460, January 2012. 276 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 277 Code: The Implementation Status Section", RFC 6982, 278 July 2013. 280 [CBC-Attack] 281 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 282 the TLS and DTLS Record Protocols", IEEE Symposium on 283 Security and Privacy , 2013. 285 [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", 286 2011, . 289 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty 290 Security Conference 2012, 2012. 292 [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", 293 2013, . 295 [RC4] Schneier, B., "Applied Cryptography: Protocols, 296 Algorithms, and Source Code in C, 2nd Ed.", 1996. 298 [RC4-Attack-FMS] 299 Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the 300 Key Scheduling Algorithm of RC4", Selected Areas in 301 Cryptography , 2001. 303 [RC4-Attack] 304 ISOBE, T., OHIGASHI, T., WATANABE, Y., and M. MORII, "Full 305 Plaintext Recovery Attack on Broadcast RC4", International 306 Workshop on Fast Software Encryption , 2013. 308 [Padding-Oracle] 309 Vaudenay, S., ""Security Flaws Induced by CBC Padding 310 Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002, 311 2002, . 314 Appendix A. Appendix: Change Log 316 Note to RFC Editor: please remove this section before publication. 318 A.1. -00 320 o Initial version. 322 Author's Address 324 Yaron Sheffer 325 Porticor 326 29 HaHarash St. 327 Hod HaSharon 4501303 328 Israel 330 Email: yaronf.ietf@gmail.com