idnits 2.17.00 (12 Aug 2021) /tmp/idnits29729/draft-sheffer-tls-bcp-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 : ---------------------------------------------------------------------------- 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 20, 2013) is 3164 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) == Unused Reference: 'TLS-IANA' is defined on line 486, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5829 == Outdated reference: draft-merkle-tls-brainpool has been published as RFC 7027 ** Downref: Normative reference to an Informational draft: draft-merkle-tls-brainpool (ref. 'I-D.merkle-tls-brainpool') == 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: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: BCP R. Holz 5 Expires: March 24, 2014 TUM 6 September 20, 2013 8 Recommendations for Secure Use of TLS and DTLS 9 draft-sheffer-tls-bcp-01 11 Abstract 13 Over the last few years there have been several serious attacks on 14 TLS, including attacks on its most commonly used ciphers and modes of 15 operation. This document offers recommendations on securely using 16 the TLS and DTLS protocols, given existing standards and 17 implementations. 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 March 24, 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 1.1. Conventions used in this document . . . . . . . . . . 3 55 2. Attacks on TLS . . . . . . . . . . . . . . . . . . . . 3 56 2.1. BEAST . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Lucky Thirteen . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . 4 59 2.4. Compression Attacks: CRIME and BREACH . . . . . . . . 4 60 3. Selection Criteria . . . . . . . . . . . . . . . . . . 4 61 4. Recommendations . . . . . . . . . . . . . . . . . . . 5 62 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Cipher Suite Negotiation Details . . . . . . . . . . . 6 64 4.3. Downgrade Attacks . . . . . . . . . . . . . . . . . . 6 65 4.4. Alternatives . . . . . . . . . . . . . . . . . . . . . 6 66 5. Implementation Status . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . 8 68 6.1. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.2. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . 8 70 6.3. Session Resumption . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . 9 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . 10 76 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 12 77 A.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Over the last few years there have been several major attacks on TLS 84 [RFC5246], including attacks on its most commonly used ciphers and 85 modes of operation. Details are given in Section 2, but suffice it 86 to say that both AES-CBC and RC4, which together make up for most 87 current usage, have been seriously attacked in the context of TLS. 89 Given these issues, there is need for IETF guidance on how TLS can be 90 used securely. Unlike most IETF documents, this is guidance for 91 deployers, as well as for implementers. In fact the recommendations 92 below call for the use of widely implemented algorithms, which are 93 not seeing widespread use today. 95 Rather than standardizing new mechanisms in TLS, our goal is to 96 recommend a few already-specified mechanisms and cipher suites, and 97 to encourage the industry to use them in order to improve the overall 98 security of TLS-protected network traffic. When picking these 99 mechanisms, we consider their security, their technical maturity and 100 interoperability, as well as their prevalence at the time of writing. 102 This recommendation applies to both TLS and DTLS. TLS 1.3, when it 103 is standardized and deployed in the field, should resolve the current 104 vulnerabilities while providing significantly better functionality, 105 and will very likely obsolete the current document. 107 Our knowledge about the strength of various algorithms and feasible 108 attacks can change quickly, and experience shows that a crypto BCP is 109 a point-in-time statement more than other BCPs. Readers are advised 110 to seek out any errata or udpates that apply to this document. 112 1.1. Conventions used in this document 114 [[Are we normative? Currently we're not and this section might go 115 away.]] 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Attacks on TLS 123 This section lists the attacks that motivated the current 124 recommendations. This is not intended to be an extensive survey of 125 TLS's security. 127 While there are widely deployed mitigations for some of the attacks 128 listed below, we believe that their root causes necessitate a more 129 systemic solution. 131 2.1. BEAST 133 The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation 134 of CBC (that is, predictable IV) to decrypt parts of a packet, and 135 specifically shows how this can be used to decrypt HTTP cookies when 136 run over TLS. 138 2.2. Lucky Thirteen 140 A consequence of the MAC-then-encrypt design in all current versions 141 of TLS is the existence of padding oracle attacks [Padding-Oracle]. 142 A recent incarnation of these attacks is the Lucky Thirteen attack 143 [CBC-Attack], a timing side-channel attack that allows the attacker 144 to decrypt arbitrary ciphertext. 146 2.3. Attacks on RC4 148 The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) 149 for many years. Attacks have also been known for a long time, e.g. 150 [RC4-Attack-FMS]. But recent attacks ([RC4-Attack], 151 [RC4-Attack-AlF]) have weakened this algorithm even more. See 152 [I-D.popov-tls-prohibiting-rc4] for more details. 154 2.4. Compression Attacks: CRIME and BREACH 156 The CRIME attack [CRIME] allows an active attacker to decrypt 157 cyphertext (specifically, cookies) when TLS is used with protocol- 158 level compression. 160 The BREACH attack [BREACH] makes similar use of HAdded TTP-level 161 compression, which is much more prevalent than compression at the TLS 162 level, to decrypt secret data passed in the HTTP response. 164 The former attack can be mitigated by disabling TLS compression, as 165 recommended below. We are not aware of mitigations at the protocol 166 level to the latter attack, and so application-level mitigations are 167 needed (see [BREACH]). For example, implementations of HTTP that use 168 CSRF tokens will need to randomize them even when the recommendations 169 of the current document are adopted. 171 3. Selection Criteria 173 Given the above attacks, we are proposing that deployers opt for a 174 specific cipher suite when negotiating TLS. We have used the 175 following criteria when framing our recommendations: 177 o The cipher suite must be secure in default use, and should not 178 require any additional security measures beyond those defined in 179 the standard. 180 o The cipher suite must be widely implemented, i.e. available in a 181 large percentage of popular cryptographic libraries. 182 o The cipher suite must have undergone a significant amount of 183 analysis, and the algorithm and mode of operation must both be 184 standardized by relevant organizations. 185 o We prefer cipher suites that provide client-side privacy and 186 perfect forward secrecy, i.e. those that use ephemeral Diffie- 187 Hellman. See Section 6.2 for more details. 188 o As currently specified and implemented, elliptic curve groups are 189 preferable over modular DH groups: they are easier and safer to 190 use within TLS. 191 o When there are multiple key sizes available, we have chosen the 192 current industry standard, 128 bits of strength. Of course 193 deployers are free to opt for a stronger cipher suite. 195 4. Recommendations 197 Following are recommendations for people implementing and deploying 198 client and server-side TLS. 200 4.1. Summary 202 Based on the criteria above, we recommend using as a preferred cipher 203 suite the following: 205 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5829] 207 It is noted that the above cipher suite is an authenticated 208 encryption (AEAD) algorithm [RFC5116], and therefore requires the use 209 of TLS 1.2. 211 We recommend using 2048-bit server certificates, with a SHA-256 212 fingerprint. See [CAB-Baseline] for more details. 214 [RFC4492] allows clients and servers to negotiate ECDH parameters 215 (curves). We recommend that clients and servers prefer verifiably 216 random curves (specifically Brainpool P-256, brainpoolp256r1 217 [I-D.merkle-tls-brainpool]), and fall back to the commonly used NIST 218 P-256 (secp256r1) [RFC4492]. In addition, clients should send an 219 ec_point_formats extension with a single element, "uncompressed". 221 We recommend to always disable TLS-level compression ([RFC5246], Sec. 223 6.2.2). 225 Finally, we recommend that clients disable fallback to SSLv3 (see 226 Section 4.3). 228 4.2. Cipher Suite Negotiation Details 230 We recommend that clients include the above cipher suite as the first 231 proposal to any server, unless they have prior knowledge that the 232 server cannot respond to a TLS 1.2 client_hello message. 234 We recommend that servers prefer this cipher suite (or a similar but 235 stronger one) whenever it is proposed, even if it is not the first 236 proposal. 238 Both clients and servers should include the "Supported Elliptic 239 Curves" extension [RFC4492]. 241 Clients are of course free to offer stronger cipher suites, e.g. 242 using AES-256; when they do, the server should prefer the stronger 243 cipher suite unless there are reasons (e.g. performance) to choose 244 otherwise. 246 Note that other profiles of TLS 1.2 exist that use different cipher 247 suites. For example, [RFC6460] defines a profile that uses the 248 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 249 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 251 This document is not an application profile standard, in the sense of 252 Sec. 9 of [RFC5246]. As a result, clients and servers are still 253 required to support the TLS mandatory cipher suite, 254 TLS_RSA_WITH_AES_128_CBC_SHA. 256 4.3. Downgrade Attacks 258 Some client implementations revert to SSLv3 if the server rejected 259 higher versions of SSL/TLS. This fallback can be forced by a MITM 260 attacker. Moreover, IP scans [[reference?]] show that SSLv3-only 261 servers amount to about 3% of the current server population. As a 262 result, we recommend that by default, clients should avoid falling 263 back to SSLv3. 265 4.4. Alternatives 267 Elliptic Curves Cryptography is not universally deployed for several 268 reasons, including its complexity compared to modular arithmetic and 269 longstanding IPR concerns. On the other hand, there are two related 270 issues hindering effective use of modular Diffie-Hellman cipher 271 suites in TLS: 273 o There are no protocol mechanisms to negotiate the DH groups or 274 parameter lengths supported by client and server. 275 o There are widely deployed client implementations that reject 276 received DH parameters, if they are longer than 1024 bits. 278 We note that with DHE and ECDHE cipher suites, the TLS master key 279 only depends on the Diffie Hellman parameters and not on the strength 280 the the RSA certificate; moreover, 1024 bits DH parameters are 281 generally considered insufficient at this time. 283 Because of the above, we recommend using (in priority order): 285 1. Elliptic Curve DHE with negotiated parameters, as described in 286 Section 4.1. 287 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 288 Diffie-Hellman parameters. 289 3. The same cipher suite, with 1024-bit parameters. 291 With modular ephemeral DH, deployers should carefully evaluate 292 interoperability vs. security considerations when configuring their 293 TLS endpoints. 295 5. Implementation Status 297 Since this document does not propose a new protocol or a new cipher 298 suite, we do not provide a full implementation status, as per 299 [RFC6982]. However it is useful to list some known existing 300 implementations of the recommended cipher suite(s). 302 +----------+--------------+---------------------+-------------------+ 303 | Category | Software | As Of Version | Comment | 304 +----------+--------------+---------------------+-------------------+ 305 | Library | OpenSSL | 1.0.1 | | 306 | | GnuTLS | | | 307 | | NSS | 3.11.1 | | 308 | Browser | Internet | IE8 on Windows 7 | | 309 | | Explorer | | | 310 | | Firefox | TBD | | 311 | | Chrome | TLS 1.2 and AES-GCM | | 312 | | | expected in Chrome | | 313 | | | 30 | | 314 | | Safari | TBD | | 315 | Web | Apache | ?? | | 316 | server | (mod_gnutls) | | | 317 | | Apache | ?? | | 318 | | (mod_ssl) | | | 319 | | Nginx | 1.0.9, 1.1.6 | With a recent | 320 | | | | version of | 321 | | | | OpenSSL | 322 +----------+--------------+---------------------+-------------------+ 324 6. Security Considerations 326 6.1. AES-GCM 328 Please refer to [RFC5246], Sec. 11 for general security 329 considerations when using TLS 1.2, and to [RFC5288], Sec. 6 for 330 security considerations that apply specifically to AES-GCM when used 331 with TLS. 333 6.2. Perfect Forward Secrecy (PFS) 335 PFS is a defense against an attacker who records encrypted 336 conversations where the session keys are only encrypted with the 337 communicating parties' long-term keys. Should the attacker be able 338 to obtain these long-term keys at some point later in the future, he 339 will be able to decrypt the session keys and thus the entire 340 conversation. In the context of TLS and DTLS, such compromise of 341 long-term keys is not entirely implausible. It can happen, for 342 example, due to: 344 o A client or server being attacked by some other attack vector, and 345 the private key retrieved. 346 o A long-term key retrieved from a device that has been sold or 347 otherwise decommissioned without prior wiping. 348 o A long-term key used on a device as a default key [Heninger2012]. 349 o A key generated by a Trusted Third Party like a CA, and later 350 retrieved from it either by extortion or compromise 351 [Soghoian2011]. 352 o A cryptographic break-through, or the use of asymmetric keys with 353 insufficient length [Kleinjung2010]. 355 PFS ensures in such cases that the session keys cannot be determined 356 even by an attacker who obtains the long-term keys some time after 357 the conversation. It also protects against an attacker who is in 358 possession of the long-term keys, but remains passive during the 359 conversation. 361 PFS is generally achieved by using the Diffie-Hellman scheme to 362 derive session keys. The Diffie-Hellman scheme has both parties 363 maintain private secrets and send parameters over the network as 364 modular powers over certain cyclic groups. The properties of the so- 365 called Discrete Logarithm Problem (DLP) allow to derive the session 366 keys without an eavesdropper being able to do so. There is currently 367 no known attack against DLP if sufficiently large parameters are 368 chosen. 370 Unfortunately, many TLS/DTLS cipher suites were defined that do not 371 enable PFS, e.g. TLS_RSA_WITH_AES_256_CBC_SHA256. We thus advocate 372 strict use of PFS-only ciphers. These are listed in Section 373 Section 4.1. 375 6.3. Session Resumption 377 TBD, https://www.imperialviolet.org/2013/06/27/botchingpfs.html. 379 7. IANA Considerations 381 [Note to RFC Editor: please remove this section before publication.] 383 This document requires no IANA actions. 385 8. Acknowledgements 387 We would like to thank Stephen Farrell, Simon Josefsson, Yoav Nir, 388 Kenny Paterson, Patrick Pelletier, and Rich Salz for their review. 389 Thanks to Brian Smith whose "browser cipher suites" page is a great 390 resource. Finally, Thanks to all others who commented on the TLS and 391 other lists and are not mentioned here by name. 393 The document was prepared using the lyx2rfc tool, created by Nico 394 Williams. 396 9. References 398 9.1. Normative References 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 404 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 405 for Transport Layer Security (TLS)", RFC 4492, May 2006. 407 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 408 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 410 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 411 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 412 August 2008. 414 [RFC5829] Brown, A., Clemm, G., and J. Reschke, "Link Relation Types 415 for Simple Version Navigation between Web Resources", 416 RFC 5829, April 2010. 418 [I-D.merkle-tls-brainpool] 419 Merkle, J. and M. Lochter, "ECC Brainpool Curves for 420 Transport Layer Security (TLS)", 421 draft-merkle-tls-brainpool-04 (work in progress), 422 July 2013. 424 9.2. Informative References 426 [I-D.popov-tls-prohibiting-rc4] 427 Popov, A., "Prohibiting RC4 Cipher Suites", 428 draft-popov-tls-prohibiting-rc4-00 (work in progress), 429 August 2013. 431 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 432 Encryption", RFC 5116, January 2008. 434 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 435 Layer Security (TLS)", RFC 6460, January 2012. 437 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 438 Code: The Implementation Status Section", RFC 6982, 439 July 2013. 441 [CBC-Attack] 442 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 443 the TLS and DTLS Record Protocols", IEEE Symposium on 444 Security and Privacy , 2013. 446 [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", 447 2011, . 450 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty 451 Security Conference 2012, 2012. 453 [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", 454 2013, . 456 [RC4] Schneier, B., "Applied Cryptography: Protocols, 457 Algorithms, and Source Code in C, 2nd Ed.", 1996. 459 [RC4-Attack-FMS] 460 Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the 461 Key Scheduling Algorithm of RC4", Selected Areas in 462 Cryptography , 2001. 464 [RC4-Attack] 465 ISOBE, T., OHIGASHI, T., WATANABE, Y., and M. MORII, "Full 466 Plaintext Recovery Attack on Broadcast RC4", International 467 Workshop on Fast Software Encryption , 2013. 469 [RC4-Attack-AlF] 470 AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., 471 and J. Schuldt, "On the Security of RC4 in TLS", Usenix 472 Security Symposium 2013, 2013, . 475 [Padding-Oracle] 476 Vaudenay, S., "Security Flaws Induced by CBC Padding 477 Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002, 478 2002, . 481 [CAB-Baseline] 482 "Baseline Requirements for the Issuance and Management of 483 Publicly-Trusted Certificates Version 1.1.6", 2013, 484 . 486 [TLS-IANA] 487 "Transport Layer Security (TLS) Parameters - TLS Cipher 488 Suite Registry", . 491 [Heninger2012] 492 Heninger, N., Durumeric, Z., Wustrow, E., and J. 493 Halderman, "Mining Your Ps and Qs: Detection of Widespread 494 Weak Keys in Network Devices", Usenix Security 495 Symposium 2012, 2012. 497 [Kleinjung2010] 498 Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", 499 CRYPTO 10, 2010. 501 [Soghoian2011] 502 Soghoian, C. and S. Stamm, "Certified lies: Detecting and 503 defeating government interception attacks against SSL.", 504 Proc. 15th Int. Conf. Financial Cryptography and Data 505 Security , 2011. 507 Appendix A. Appendix: Change Log 509 Note to RFC Editor: please remove this section before publication. 511 A.1. -01 513 o Clarified our motivation in the introduction. 514 o Added a section justifying the need for PFS. 515 o Added recommendations for RSA and DH parameter lengths. Moved 516 from DHE to ECDHE, with a discussion on whether/when DHE is 517 appropriate. 518 o Recommendation to avoid fallback to SSLv3. 519 o Initial information about browser support - more still needed! 520 o More clarity on compression. 521 o Client can offer stronger cipher suites. 522 o Discussion of the regular TLS mandatory cipher suite. 524 A.2. -00 526 o Initial version. 528 Authors' Addresses 530 Yaron Sheffer 531 Porticor 532 29 HaHarash St. 533 Hod HaSharon 4501303 534 Israel 536 Email: yaronf.ietf@gmail.com 538 Ralph Holz 539 Technische Universitaet Muenchen 540 Boltzmannstr. 3 541 Garching 85748 542 Germany 544 Email: holz@net.in.tum.de