idnits 2.17.1 draft-ietf-uta-tls-bcp-10.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 date (February 20, 2015) is 3353 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 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-10 == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-06 == Outdated reference: A later version (-05) exists of draft-ietf-tls-downgrade-scsv-02 == Outdated reference: A later version (-06) exists of draft-ietf-tls-session-hash-03 == Outdated reference: A later version (-03) exists of draft-ietf-tls-sslv3-diediedie-00 == Outdated reference: A later version (-07) exists of draft-ietf-uta-xmpp-05 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Best Current Practice R. Holz 5 Expires: August 24, 2015 TUM 6 P. Saint-Andre 7 &yet 8 February 20, 2015 10 Recommendations for Secure Use of TLS and DTLS 11 draft-ietf-uta-tls-bcp-10 13 Abstract 15 Transport Layer Security (TLS) and Datagram Transport Layer Security 16 (DTLS) are widely used to protect data exchanged over application 17 protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the 18 last few years, several serious attacks on TLS have emerged, 19 including attacks on its most commonly used cipher suites and their 20 modes of operation. This document provides recommendations for 21 improving the security of deployed services that use TLS and DTLS. 22 The recommendations are applicable to the majority of use cases. 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 August 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. General Recommendations . . . . . . . . . . . . . . . . . . . 4 61 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 4 63 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 5 64 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 6 65 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 7 68 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 8 69 3.6. Server Name Indication . . . . . . . . . . . . . . . . . 8 70 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 8 71 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 8 72 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 10 73 4.2.1. Implementation Details . . . . . . . . . . . . . . . 11 74 4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 11 75 4.4. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 12 76 4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 13 77 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 13 78 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 14 79 5.2. Unauthenticated TLS and Opportunistic Security . . . . . 15 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 16 83 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 17 85 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 18 86 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 18 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 90 9.2. Informative References . . . . . . . . . . . . . . . . . 21 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 92 A.1. draft-ietf-uta-tls-bcp-08 . . . . . . . . . . . . . . . . 25 93 A.2. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 25 94 A.3. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 25 95 A.4. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 25 96 A.5. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 26 97 A.6. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 26 98 A.7. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 26 99 A.8. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 26 100 A.9. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 27 101 A.10. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 27 102 A.11. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 27 103 A.12. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 106 1. Introduction 108 Transport Layer Security (TLS) [RFC5246] and Datagram Transport 109 Security Layer (DTLS) [RFC6347] are widely used to protect data 110 exchanged over application protocols such as HTTP, SMTP, IMAP, POP, 111 SIP, and XMPP. Over the last few years, several serious attacks on 112 TLS have emerged, including attacks on its most commonly used cipher 113 suites and their modes of operation. For instance, both the AES-CBC 114 [RFC3602] and RC4 [RFC7465] encryption algorithms, which together 115 have been the most widely deployed ciphers, have been attacked in the 116 context of TLS. A companion document [RFC7457] provides detailed 117 information about these attacks and will help the reader understand 118 the rationale behind the recommendations provided here. 120 Because of these attacks, those who implement and deploy TLS and DTLS 121 need updated guidance on how TLS can be used securely. This document 122 provides guidance for deployed services as well as for software 123 implementations, assuming the implementer expects his or her code to 124 be deployed in environments defined in Section 5. In fact, this 125 document calls for the deployment of algorithms that are widely 126 implemented but not yet widely deployed. Concerning deployment, this 127 document targets a wide audience, namely all deployers who wish to 128 add authentication (be it one-way only or mutual), confidentiality, 129 and data integrity protection to their communications. 131 The recommendations herein take into consideration the security of 132 various mechanisms, their technical maturity and interoperability, 133 and their prevalence in implementations at the time of writing. 134 Unless it is explicitly called out that a recommendation applies to 135 TLS alone or to DTLS alone, each recommendation applies to both TLS 136 and DTLS. 138 It is expected that the TLS 1.3 specification will resolve many of 139 the vulnerabilities listed in this document. A system that deploys 140 TLS 1.3 should have fewer vulnerabilities than TLS 1.2 or below. 141 This document is likely to be updated after TLS 1.3 gets noticeable 142 deployment. 144 These are minimum recommendations for the use of TLS in the vast 145 majority of implementation and deployment scenarios, with the 146 exception of unauthenticated TLS (see Section 5). Other 147 specifications that reference this document can have stricter 148 requirements related to one or more aspects of the protocol, based on 149 their particular circumstances (e.g., for use with a particular 150 application protocol); when that is the case, implementers are 151 advised to adhere to those stricter requirements. Furthermore, this 152 document provides a floor, not a ceiling, so stronger options are 153 always allowed (e.g., depending on differing evaluations of the 154 importance of cryptographic strength vs. computational load). 156 Community knowledge about the strength of various algorithms and 157 feasible attacks can change quickly, and experience shows that a 158 security BCP is a point-in-time statement. Readers are advised to 159 seek out any errata or updates that apply to this document. 161 2. Terminology 163 A number of security-related terms in this document are used in the 164 sense defined in [RFC4949]. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 3. General Recommendations 172 This section provides general recommendations on the secure use of 173 TLS. Recommendations related to cipher suites are discussed in the 174 following section. 176 3.1. Protocol Versions 178 3.1.1. SSL/TLS Protocol Versions 180 It is important both to stop using old, less secure versions of SSL/ 181 TLS and to start using modern, more secure versions; therefore, the 182 following are the recommendations concerning TLS/SSL protocol 183 versions: 185 o Implementations MUST NOT negotiate SSL version 2. 187 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 189 o Implementations MUST NOT negotiate SSL version 3. 191 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 192 plugged some significant security holes, but did not support 193 strong cipher suites. SSLv3 does not support TLS extensions, some 194 of which (e.g., renegotiation_info) are security-critical. In 195 addition, with the emergence of the POODLE attack [POODLE], SSLv3 196 is now widely recognized as fundamentally insecure. See 197 [I-D.ietf-tls-sslv3-diediedie] for further details. 199 o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246] 200 unless no higher version is available in the negotiation. 202 Rationale: TLS 1.0 (published in 1999) does not support many 203 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 204 record IV for CBC-based cipher suites and does not warn against 205 common padding errors. 207 o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346] 208 unless no higher version is available in the negotiation. 210 Rationale: TLS 1.1 (published in 2006) is a security improvement 211 over TLS 1.0, but still does not support certain stronger cipher 212 suites. 214 o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to 215 negotiate TLS version 1.2 over earlier versions of TLS. 217 Rationale: Several stronger cipher suites are available only with 218 TLS 1.2 (published in 2008). In fact, the cipher suites 219 recommended by this document (Section 4.2 below) are only 220 available in TLS 1.2. 222 This BCP applies to TLS 1.2, and also to earlier versions. It is not 223 safe for readers to assume that the recommendations in this BCP apply 224 to any future version of TLS. 226 3.1.2. DTLS Protocol Versions 228 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 229 1.1 was published. The following are the recommendations with 230 respect to DTLS: 232 o Implementations SHOULD NOT negotiate DTLS version 1.0 [RFC4347]. 234 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 236 o Implementations MUST support, and prefer to negotiate, DTLS 237 version 1.2 [RFC6347]. 239 Version 1.2 of DTLS correlates to Version 1.2 of TLS (see above). 240 (There is no Version 1.1 of DTLS.) 242 3.1.3. Fallback to Lower Versions 244 Clients that "fall back" to lower versions of the protocol after the 245 server rejects higher versions of the protocol MUST NOT fall back to 246 SSLv3 or earlier. 248 Rationale: Some client implementations revert to lower versions of 249 TLS or even to SSLv3 if the server rejected higher versions of the 250 protocol. This fallback can be forced by a man in the middle (MITM) 251 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 252 1.2, the version recommended by this document. While TLS 1.0-only 253 servers are still quite common, IP scans show that SSLv3-only servers 254 amount to only about 3% of the current Web server population. (At 255 the time of this writing, an explicit method for preventing downgrade 256 attacks is being defined in [I-D.ietf-tls-downgrade-scsv].) 258 3.2. Strict TLS 260 The following recommendations are provided to help prevent SSL 261 Stripping (the attack is summarized in Section 2.1 of [RFC7457]): 263 o In cases where an application protocol allows implementations or 264 deployments a choice between strict TLS configuration and dynamic 265 upgrade from unencrypted to TLS-protected traffic (such as 266 STARTTLS), clients and servers SHOULD prefer strict TLS 267 configuration. 269 o Application protocols typically provide a way for the server to 270 offer TLS during an initial protocol exchange, and sometimes also 271 provide a way for the server to advertise support for TLS (e.g., 272 through a flag indicating that TLS is required); unfortunately, 273 these indications are sent before the communication channel is 274 encrypted. A client SHOULD attempt to negotiate TLS even if these 275 indications are not communicated by the server. 277 o HTTP client and server implementations MUST support the HTTP 278 Strict Transport Security (HSTS) header [RFC6797], in order to 279 allow Web servers to advertise that they are willing to accept 280 TLS-only clients. 282 o Web servers SHOULD use HSTS to indicate that they are willing to 283 accept TLS-only clients, unless they are deployed in such a way 284 that using HSTS would in fact weaken overall security (e.g., it 285 can be problematic to use HSTS with self-signed certificates, as 286 described in Section 11.3 of [RFC6797]). 288 Rationale: Combining unprotected and TLS-protected communication 289 opens the way to SSL Stripping and similar attacks, since an initial 290 part of the communication is not integrity protected and therefore 291 can be manipulated by an attacker whose goal is to keep the 292 communication in the clear. 294 3.3. Compression 296 In order to help prevent compression-related attacks (summarized in 297 Section 2.6 of [RFC7457]), implementations and deployments SHOULD 298 disable TLS-level compression ([RFC5246], Section 6.2.2), unless the 299 application protocol in question has been shown not to be open to 300 such attacks. 302 Rationale: TLS compression has been subject to security attacks, such 303 as the CRIME attack. 305 Implementers should note that compression at higher protocol levels 306 can allow an active attacker to extract cleartext information from 307 the connection. The BREACH attack is one such case. These issues 308 can only be mitigated outside of TLS and are thus out of scope of the 309 current document. See Section 2.6 of [RFC7457] for further details. 311 3.4. TLS Session Resumption 313 If TLS session resumption is used, care ought to be taken to do so 314 safely. In particular, when using session tickets [RFC5077], the 315 resumption information MUST be authenticated and encrypted to prevent 316 modification or eavesdropping by an attacker. Further 317 recommendations apply to session tickets: 319 o A strong cipher suite MUST be used when encrypting the ticket (as 320 least as strong as the main TLS cipher suite). 322 o Ticket keys MUST be changed regularly, e.g., once every week, so 323 as not to negate the benefits of forward secrecy (see Section 7.3 324 for details on forward secrecy). 326 o For similar reasons, session ticket validity SHOULD be limited to 327 a reasonable duration (e.g., half as long as ticket key validity). 329 Rationale: session resumption is another kind of TLS handshake, and 330 therefore must be as secure as the initial handshake. This document 331 (Section 4) recommends the use of cipher suites that provide forward 332 secrecy, i.e. that prevent an attacker who gains momentary access to 333 the TLS endpoint (either client or server) and its secrets from 334 reading either past or future communication. The tickets must be 335 managed so as not to negate this security property. 337 3.5. TLS Renegotiation 339 Where handshake renegotiation is implemented, both clients and 340 servers MUST implement the renegotiation_info extension, as defined 341 in [RFC5746]. 343 The most secure option for countering the Triple Handshake attack is 344 to refuse any change of certificates during renegotiation. In 345 addition, TLS clients SHOULD apply the same validation policy for all 346 certificates received over a connection. The [triple-handshake] 347 document suggests several other possible countermeasures, such as 348 binding the master secret to the full handshake (see 349 [I-D.ietf-tls-session-hash]) and binding the abbreviated session 350 resumption handshake to the original full handshake. Although the 351 latter two techniques are still under development and thus do not 352 qualify as current practices, those who implement and deploy TLS are 353 advised to watch for further development of appropriate 354 countermeasures. 356 3.6. Server Name Indication 358 TLS implementations MUST support the Server Name Indication (SNI) 359 extension defined in Section 3 of [RFC6066] for those higher level 360 protocols which would benefit from it, including HTTPS. However, 361 unlike implementation, the use of SNI in particular circumstances is 362 a matter of local policy. 364 Rationale: SNI supports deployment of multiple TLS-protected virtual 365 servers on a single address, and therefore enables fine-grained 366 security for these virtual servers, by allowing each one to have its 367 own certificate. 369 4. Recommendations: Cipher Suites 371 TLS and its implementations provide considerable flexibility in the 372 selection of cipher suites. Unfortunately, some available cipher 373 suites are insecure, some do not provide the targeted security 374 services, and some no longer provide enough security. Incorrectly 375 configuring a server leads to no or reduced security. This section 376 includes recommendations on the selection and negotiation of cipher 377 suites. 379 4.1. General Guidelines 381 Cryptographic algorithms weaken over time as cryptanalysis improves: 382 algorithms that were once considered strong become weak. Such 383 algorithms need to be phased out over time and replaced with more 384 secure cipher suites. This helps to ensure that the desired security 385 properties still hold. SSL/TLS has been in existence for almost 20 386 years and many of the cipher suites that have been recommended in 387 various versions of SSL/TLS are now considered weak or at least not 388 as strong as desired. Therefore this section modernizes the 389 recommendations concerning cipher suite selection: 391 o Implementations MUST NOT negotiate the cipher suites with NULL 392 encryption. 394 Rationale: The NULL cipher suites do not encrypt traffic and so 395 provide no confidentiality services. Any entity in the network 396 with access to the connection can view the plaintext of contents 397 being exchanged by the client and server. (Nevertheless, this 398 document does not discourage software from implementing NULL 399 cipher suites, since they can be useful for testing and 400 debugging.) 402 o Implementations MUST NOT negotiate RC4 cipher suites. 404 Rationale: The RC4 stream cipher has a variety of cryptographic 405 weaknesses, as documented in [RFC7465]. Note that DTLS 406 specifically forbids the use of RC4 already. 408 o Implementations MUST NOT negotiate cipher suites offering less 409 than 112 bits of security, including so-called "export-level" 410 encryption (which provide 40 or 56 bits of security). 412 Rationale: Based on [RFC3766], at least 112 bits of security is 413 needed. 40-bit and 56-bit security are considered insecure today. 414 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. 416 o Implementations SHOULD NOT negotiate cipher suites that use 417 algorithms offering less than 128 bits of security. 419 Rationale: Cipher suites that offer between 112-bits and 128-bits 420 of security are not considered weak at this time, however it is 421 expected that their useful lifespan is short enough to justify 422 supporting stronger cipher suites at this time. 128-bit ciphers 423 are expected to remain secure for at least several years, and 424 256-bit ciphers until the next fundamental technology 425 breakthrough. Note that, because of so-called "meet-in-the- 426 middle" attacks [Multiple-Encryption] some legacy cipher suites 427 (e.g., 168-bit 3DES) have an effective key length which is smaller 428 than their nominal key length (112 bits in the case of 3DES). 429 Such cipher suites should be evaluated according to their 430 effective key length. 432 o Implementations SHOULD NOT negotiate cipher suites based on RSA 433 key transport, a.k.a. "static RSA". 435 Rationale: These cipher suites, which have assigned values 436 starting with the string "TLS_RSA_WITH_*", have several drawbacks, 437 especially the fact that they do not support forward secrecy. 439 o Implementations MUST support and prefer to negotiate, cipher 440 suites offering forward secrecy, such as those in the Ephemeral 441 Diffie-Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" 442 and "ECDHE") families. 444 Rationale: Forward secrecy (sometimes called "perfect forward 445 secrecy") prevents the recovery of information that was encrypted 446 with older session keys, thus limiting the amount of time during 447 which attacks can be successful. See Section 7.3 for a detailed 448 discussion. 450 4.2. Recommended Cipher Suites 452 Given the foregoing considerations, implementation and deployment of 453 the following cipher suites is RECOMMENDED: 455 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 457 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 459 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 461 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 463 These cipher suites are supported only in TLS 1.2 because they are 464 authenticated encryption (AEAD) algorithms [RFC5116]. 466 Typically, in order to prefer these suites, the order of suites needs 467 to be explicitly configured in server software (see [BETTERCRYPTO] 468 for helpful deployment guidelines, but note that its recommendations 469 differ from the current document in some details). It would be ideal 470 if server software implementations were to prefer these suites by 471 default. 473 Some devices have hardware support for AES-CCM but not AES-GCM, so 474 they are unable to follow the foregoing recommendations regarding 475 cipher suites. There are even devices that do not support public key 476 cryptography at all, but they are out of scope entirely. 478 4.2.1. Implementation Details 480 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 481 first proposal to any server, unless they have prior knowledge that 482 the server cannot respond to a TLS 1.2 client_hello message. 484 Servers MUST prefer this cipher suite over weaker cipher suites 485 whenever it is proposed, even if it is not the first proposal. 487 Clients are of course free to offer stronger cipher suites, e.g., 488 using AES-256; when they do, the server SHOULD prefer the stronger 489 cipher suite unless there are compelling reasons (e.g., seriously 490 degraded performance) to choose otherwise. 492 This document does not change the mandatory-to-implement TLS cipher 493 suite(s) prescribed by TLS. To maximize interoperability, RFC 5246 494 mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher 495 suite, which is significantly weaker than the cipher suites 496 recommended here (the GCM mode does not suffer from the same 497 weakness, caused by the order of MAC-then-Encrypt in TLS 498 [Krawczyk2001], since it uses an Authenticated Encryption with 499 Associated Data (AEAD) mode of operation). Implementers should 500 consider the interoperability gain against the loss in security when 501 deploying the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. Other 502 application protocols specify other cipher suites as mandatory to 503 implement (MTI). 505 Note that some profiles of TLS 1.2 use different cipher suites. For 506 example, [RFC6460] defines a profile that uses the 507 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 508 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 510 [RFC4492] allows clients and servers to negotiate ECDH parameters 511 (curves). Both clients and servers SHOULD include the "Supported 512 Elliptic Curves" extension [RFC4492]. For interoperability, clients 513 and servers SHOULD support the NIST P-256 (secp256r1) curve 514 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 515 extension with a single element, "uncompressed". 517 4.3. Public Key Length 519 When using the cipher suites recommended in this document, two public 520 keys are normally used in the TLS handshake: one for the Diffie- 521 Hellman key agreement and one for server authentication. Where a 522 client certificate is used, a third public key is added. 524 With a key exchange based on modular Diffie-Hellman ("DHE" cipher 525 suites), DH key lengths of at least 2048 bits are RECOMMENDED. 527 Rationale: For various reasons, in practice DH keys are typically 528 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 529 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 530 would be roughly equivalent to only an 80-bit symmetric key 531 [RFC3766], it is better to use keys longer than that for the "DHE" 532 family of cipher suites. A DH key of 1926 bits would be roughly 533 equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048 534 bits might be sufficient for at least the next 10 years 535 [NIST.SP.800-56A]. See Section 4.4 for additional information on the 536 use of modular Diffie-Hellman in TLS. 538 As noted in [RFC3766], correcting for the emergence of a TWIRL 539 machine would imply that 1024-bit DH keys yield about 65 bits of 540 equivalent strength and that a 2048-bit DH key would yield about 92 541 bits of equivalent strength. 543 With regard to ECDH keys, the IANA named curve registry contains 544 160-bit elliptic curves which are considered to be roughly equivalent 545 to only an 80-bit symmetric key [ECRYPT-II]. Curves of less than 546 192-bits SHOULD NOT be used. 548 When using RSA servers SHOULD authenticate using certificates with at 549 least a 2048-bit modulus for the public key. In addition, the use of 550 the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for 551 more details). Clients SHOULD indicate to servers that they request 552 SHA-256, by using the "Signature Algorithms" extension defined in 553 TLS 1.2. 555 4.4. Modular vs. Elliptic Curve DH Cipher Suites 557 Not all TLS implementations support both modular and elliptic curve 558 Diffie-Hellman groups, as required by Section 4.2. Some 559 implementations are severely limited in the length of DH values. 560 When such implementations need to be accommodated, the following are 561 RECOMMENDED (in priority order): 563 1. Elliptic Curve DHE with appropriately negotiated parameters 564 (e.g., the curve to be used) and a MAC algorithm stronger than 565 HMAC-SHA1 [RFC5289] 567 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 568 Diffie-Hellman parameters 570 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters. 572 Rationale: Although Elliptic Curve Cryptography is widely deployed 573 there are some communities where its uptake has been limited for 574 several reasons, including its complexity compared to modular 575 arithmetic and longstanding perceptions of IPR concerns (which, for 576 the most part, have now been resolved [RFC6090]). Note that ECDHE 577 cipher suites exist for both RSA and ECDSA certificates so moving to 578 ECDHE cipher suites does not require moving away from RSA based 579 certificates. On the other hand, there are two related issues 580 hindering effective use of modular Diffie-Hellman cipher suites in 581 TLS: 583 o There are no standardized, widely implemented protocol mechanisms 584 to negotiate the DH groups or parameter lengths supported by 585 client and server. 587 o Many servers choose DH parameters of 1024 bits or fewer. 589 o There are widely deployed client implementations that reject 590 received DH parameters if they are longer than 1024 bits. In 591 addition, several implementations do not perform appropriate 592 validation of group parameters and are vulnerable to attacks 593 referenced in Section 2.9 of [RFC7457] 595 Note that with DHE and ECDHE cipher suites, the TLS master key only 596 depends on the Diffie-Hellman parameters and not on the strength of 597 the RSA certificate; moreover, 1024 bit modular DH parameters are 598 generally considered insufficient at this time. 600 With modular ephemeral DH, deployers ought to carefully evaluate 601 interoperability vs. security considerations when configuring their 602 TLS endpoints. 604 4.5. Truncated HMAC 606 Implementations MUST NOT use the Truncated HMAC extension, defined in 607 Section 7 of [RFC6066]. 609 Rationale: the extension does not apply to the AEAD cipher suites 610 recommended above. However it does apply to most other TLS cipher 611 suites. Its use has been shown to be insecure in [PatersonRS11]. 613 5. Applicability Statement 615 The recommendations of this document primarily apply to the 616 implementation and deployment of application protocols that are most 617 commonly used with TLS and DTLS on the Internet today. Examples 618 include, but are not limited to: 620 o Web software and services that wish to protect HTTP traffic with 621 TLS. 623 o Email software and services that wish to protect IMAP, POP3, or 624 SMTP traffic with TLS. 626 o Instant-messaging software and services that wish to protect XMPP 627 or IRC traffic with TLS. 629 o Realtime media software and services that wish to protect SRTP 630 traffic with DTLS. 632 This document does not modify the implementation and deployment 633 recommendations (e.g., mandatory-to-implement cipher suites) 634 prescribed by existing application protocols that employ TLS or DTLS. 635 If the community that uses such an application protocol wishes to 636 modernize its usage of TLS or DTLS to be consistent with the best 637 practices recommended here, it needs to explicitly update the 638 existing application protocol definition (one example is 639 [I-D.ietf-uta-xmpp], which updates [RFC6120]). 641 Designers of new application protocols developed through the Internet 642 Standards Process are expected to conform to the best practices 643 recommended here, unless they provide documentation of compelling 644 reasons that would prevent such conformance (e.g., widespread 645 deployment on constrained devices that lack support for the necessary 646 algorithms). 648 5.1. Security Services 650 This document provides recommendations for an audience that wishes to 651 secure their communication with TLS to achieve the following: 653 o Confidentiality: all application-layer communication is encrypted 654 with the goal that no party should be able to decrypt it except 655 the intended receiver. 657 o Data integrity: any changes made to the communication in transit 658 are detectable by the receiver. 660 o Authentication: an end-point of the TLS communication is 661 authenticated as the intended entity to communicate with. 663 With regard to authentication, TLS enables authentication of one or 664 both end-points in the communication. Although some TLS usage 665 scenarios do not require authentication, those scenarios are not in 666 scope for this document (a rationale for this decision is provided 667 under Section 5.2). 669 If deployers deviate from the recommendations given in this document, 670 they need to be aware that they might lose access to one of the 671 foregoing security services. 673 This document applies only to environments where confidentiality is 674 required. It recommends algorithms and configuration options that 675 enforce secrecy of the data-in-transit. 677 This document also assumes that data integrity protection is always 678 one of the goals of a deployment. In cases where integrity is not 679 required, it does not make sense to employ TLS in the first place. 680 There are attacks against confidentiality-only protection that 681 utilize the lack of integrity to also break confidentiality (see for 682 instance [DegabrieleP07] in the context of IPsec). 684 This document addresses itself to application protocols that are most 685 commonly used on the Internet with TLS and DTLS. Typically, all 686 communication between TLS clients and TLS servers requires all three 687 of the above security services. This is particularly true where TLS 688 clients are user agents like Web browsers or email software. 690 This document does not address the rarer deployment scenarios where 691 one of the above three properties is not desired, such as the use 692 case described under Section 5.2 below. As another scenario where 693 confidentiality is not needed, consider a monitored network where the 694 authorities in charge of the respective traffic domain require full 695 access to unencrypted (plaintext) traffic, and where users 696 collaborate and send their traffic in the clear. 698 5.2. Unauthenticated TLS and Opportunistic Security 700 Several important applications use TLS to protect data between a TLS 701 client and a TLS server, but do so without the TLS client necessarily 702 verifying the server's certificate. This practice is often called 703 "unauthenticated TLS". The reader is referred to 704 [I-D.ietf-dane-smtp-with-dane] for an example and an explanation of 705 why this less secure practice will likely remain common in the 706 context of SMTP (especially for MTA-to-MTA communications). The 707 practice is also encountered in similar contexts such as server-to- 708 server traffic on the XMPP network (where multi-tenant hosting 709 environments make it difficult for operators to obtain proper 710 certificates for all of the domains they service). 712 Furthermore, in some scenarios the use of TLS itself is optional, 713 i.e. the client decides dynamically ("opportunistically") whether to 714 use TLS with a particular server or to connect in the clear. This 715 practice, often called "opportunistic security", is described at 716 length in [RFC7435]. 718 It can be argued that the recommendations provided in this document 719 ought to apply equally to unauthenticated TLS as well as 720 authenticated TLS. That would keep TLS implementations and 721 deployments in sync, which is a desirable property given that servers 722 can be used simultaneously for unauthenticated TLS and for 723 authenticated TLS (indeed, a server cannot know whether a client 724 might attempt authenticated or unauthenticated TLS). On the other 725 hand, it has been argued that some of the recommendations in this 726 document might be too strict for unauthenticated scenarios and that 727 any security is better than no security at all (i.e., sending traffic 728 in the clear), even if it means deploying outdated protocol versions 729 and ciphers in unauthenticated scenarios. The sense of the UTA 730 Working Group was to complete work on this document about 731 authenticated TLS and to initiate work on a separate document about 732 unauthenticated TLS. 734 In summary: this document does not apply to unauthenticated TLS use 735 cases. 737 6. IANA Considerations 739 This document requests no actions of IANA. [Note to RFC Editor: 740 please remove this whole section before publication.] 742 7. Security Considerations 744 This entire document discusses the security practices directly 745 affecting applications using the TLS protocol. This section contains 746 broader security considerations related to technologies used in 747 conjunction with or by TLS. 749 7.1. Host Name Validation 751 Application authors should take note that TLS implementations 752 frequently do not validate host names and must therefore determine if 753 the TLS implementation they are using does and, if not, write their 754 own validation code or consider changing the TLS implementation. 756 It is noted that the requirements regarding host name validation (and 757 in general, binding between the TLS layer and the protocol that runs 758 above it) vary between different protocols. For HTTPS, these 759 requirements are defined by Section 3 of [RFC2818]. 761 Readers are referred to [RFC6125] for further details regarding 762 generic host name validation in the TLS context. In addition, the 763 RFC contains a long list of example protocols, some of which 764 implement a policy very different from HTTPS. 766 If the host name is discovered indirectly and in an insecure manner 767 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 768 NOT be used as a reference identifier [RFC6125] even when it matches 769 the presented certificate. This proviso does not apply if the host 770 name is discovered securely (for further discussion, see for example 771 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]). 773 Host name validation typically applies only to the leaf "end entity" 774 certificate. Naturally, in order to ensure proper authentication in 775 the context of the PKI, application clients need to verify the entire 776 certification path in accordance with [RFC5280] (see also [RFC6125]). 778 7.2. AES-GCM 780 Section 4.2 above recommends the use of the AES-GCM authenticated 781 encryption algorithm. Please refer to [RFC5246], Section 11 for 782 general security considerations when using TLS 1.2, and to [RFC5288], 783 Section 6 for security considerations that apply specifically to AES- 784 GCM when used with TLS. 786 7.3. Forward Secrecy 788 Forward secrecy (also often called Perfect Forward Secrecy or "PFS" 789 and defined in [RFC4949]) is a defense against an attacker who 790 records encrypted conversations where the session keys are only 791 encrypted with the communicating parties' long-term keys. Should the 792 attacker be able to obtain these long-term keys at some point later 793 in time, he will be able to decrypt the session keys and thus the 794 entire conversation. In the context of TLS and DTLS, such compromise 795 of long-term keys is not entirely implausible. It can happen, for 796 example, due to: 798 o A client or server being attacked by some other attack vector, and 799 the private key retrieved. 801 o A long-term key retrieved from a device that has been sold or 802 otherwise decommissioned without prior wiping. 804 o A long-term key used on a device as a default key [Heninger2012]. 806 o A key generated by a Trusted Third Party like a CA, and later 807 retrieved from it either by extortion or compromise 808 [Soghoian2011]. 810 o A cryptographic break-through, or the use of asymmetric keys with 811 insufficient length [Kleinjung2010]. 813 o Social engineering attacks against system administrators. 815 o Collection of private keys from inadequately protected backups. 817 Forward secrecy ensures in such cases that the session keys cannot be 818 determined even by an attacker who obtains the long-term keys some 819 time after the conversation. It also protects against an attacker 820 who is in possession of the long-term keys, but remains passive 821 during the conversation. 823 Forward secrecy is generally achieved by using the Diffie-Hellman 824 scheme to derive session keys. The Diffie-Hellman scheme has both 825 parties maintain private secrets and send parameters over the network 826 as modular powers over certain cyclic groups. The properties of the 827 so-called Discrete Logarithm Problem (DLP) allow the parties to 828 derive the session keys without an eavesdropper being able to do so. 829 There is currently no known attack against DLP if sufficiently large 830 parameters are chosen. A variant of the Diffie-Hellman scheme uses 831 Elliptic Curves instead of the originally proposed modular 832 arithmetics. 834 Unfortunately, many TLS/DTLS cipher suites were defined that do not 835 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This 836 document therefore advocates strict use of forward-secrecy-only 837 ciphers. 839 7.4. Diffie-Hellman Exponent Reuse 841 For performance reasons, many TLS implementations reuse Diffie- 842 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 843 connections. Such reuse can result in major security issues: 845 o If exponents are reused for a long time (e.g., more than a few 846 hours), an attacker who gains access to the host can decrypt 847 previous connections. In other words, exponent reuse negates the 848 effects of forward secrecy. 850 o TLS implementations that reuse exponents should test the DH public 851 key they receive for group membership, in order to avoid some 852 known attacks. These tests are not standardized in TLS at the 853 time of writing. See [RFC6989] for recipient tests required of 854 IKEv2 implementations that reuse DH exponents. 856 7.5. Certificate Revocation 858 The following considerations and recommendations represent the 859 current state of the art regarding certificate revocation, even 860 though no complete and efficient solution exists for the problem of 861 checking the revocation status of common public key certificates 862 [RFC5280]: 864 o Although Certificate Revocation Lists (CRLs) are the most widely 865 supported mechanism for distributing revocation information, they 866 have known scaling challenges that limit their usefulness (despite 867 workarounds such as partitioned CRLS and delta CRLs). 869 o Proprietary mechanisms that embed revocation lists in the Web 870 browser's configuration database cannot scale beyond a small 871 number of the most heavily used Web servers. 873 o The On-Line Certification Status Protocol (OCSP) [RFC6960] 874 presents both scaling and privacy issues. In addition, clients 875 typically "soft-fail", meaning that they do not abort the TLS 876 connection if the OCSP server does not respond (however, this 877 might be a workaround to avoid denial of service attacks if an 878 OSCP responder is taken offline). 880 o OCSP stapling (Section 8 of [RFC6066]) resolves the operational 881 issues with OCSP, but is still ineffective in the presence of a 882 MITM attacker because the attacker can simply ignore the client's 883 request for a stapled OCSP response. 885 o OCSP stapling as defined in [RFC6066] does not extend to 886 intermediate certificates used in a certificate chain. Although 887 [RFC6961] addresses this shortcoming, it is a recent addition 888 without much deployment. 890 o Both CRLs and OSCP depend on relatively reliable connectivity to 891 the Internet, which might not be available to certain kinds of 892 nodes (such as newly provisioned devices that need to establish a 893 secure connection in order to boot up for the first time). 895 With regard to common public key certificates, servers SHOULD support 896 the following as a best practice given the current state of the art 897 and as a foundation for a possible future solution: 899 1. OCSP [RFC6960] 901 2. Both the status_request extension defined in [RFC6066] and the 902 status_request_v2 extension defined in [RFC6961] (this might 903 enable interoperability with the widest range of clients) 905 3. The OCSP stapling extension defined in [RFC6961] 907 The considerations in this section do not apply to scenarios where 908 the DANE-TLSA resource record [RFC6698] is used to signal to a client 909 which certificate a server considers valid and good to use for TLS 910 connections. 912 8. Acknowledgments 914 Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen 915 Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson 916 Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, 917 Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom 918 Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean 919 Turner, and Aaron Zauner for their feedback and suggested 920 improvements. Thanks also to Brian Smith, who has provided a great 921 resource in his "Proposal to Change the Default TLS Ciphersuites 922 Offered by Browsers" [Smith2013]. Finally, thanks to all others who 923 commented on the TLS, UTA, and other discussion lists but who are not 924 mentioned here by name. 926 Robert Sparks and Dave Waltermire provided helpful reviews on behalf 927 of the General Area Review Team and the Security Directorate, 928 respectively. 930 During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins, 931 Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick 932 provided comments that led to further improvements. 934 The authors gratefully acknowledge the assistance of Leif Johansson 935 and Orit Levin as the working group chairs and Pete Resnick as the 936 sponsoring Area Director. 938 9. References 940 9.1. Normative References 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, March 1997. 945 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 947 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 948 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 949 RFC 3766, April 2004. 951 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 952 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 953 for Transport Layer Security (TLS)", RFC 4492, May 2006. 955 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 956 4949, August 2007. 958 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 959 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 961 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 962 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 963 August 2008. 965 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 966 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 967 August 2008. 969 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 970 "Transport Layer Security (TLS) Renegotiation Indication 971 Extension", RFC 5746, February 2010. 973 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 974 Extension Definitions", RFC 6066, January 2011. 976 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 977 Verification of Domain-Based Application Service Identity 978 within Internet Public Key Infrastructure Using X.509 979 (PKIX) Certificates in the Context of Transport Layer 980 Security (TLS)", RFC 6125, March 2011. 982 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 983 (SSL) Version 2.0", RFC 6176, March 2011. 985 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 986 Security Version 1.2", RFC 6347, January 2012. 988 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 989 February 2015. 991 9.2. Informative References 993 [BETTERCRYPTO] 994 bettercrypto.org, , "Applied Crypto Hardening", 2015, 995 . 998 [CAB-Baseline] 999 CA/Browser Forum, , "Baseline Requirements for the 1000 Issuance and Management of Publicly-Trusted Certificates 1001 Version 1.1.6", 2013, . 1004 [DegabrieleP07] 1005 Degabriele, J. and K. Paterson, "Attacking the IPsec 1006 standards in encryption-only configurations", 2007, 1007 . 1009 [ECRYPT-II] 1010 Smart, N., "ECRYPT II Yearly Report on Algorithms and 1011 Keysizes (2011-2012)", 2012, 1012 . 1014 [Heninger2012] 1015 Heninger, N., Durumeric, Z., Wustrow, E., and J. 1016 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1017 Weak Keys in Network Devices", Usenix Security Symposium 1018 2012, 2012. 1020 [I-D.ietf-dane-smtp-with-dane] 1021 Dukhovni, V. and W. Hardaker, "SMTP security via 1022 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 1023 (work in progress), May 2014. 1025 [I-D.ietf-dane-srv] 1026 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1027 Based Authentication of Named Entities (DANE) TLSA Records 1028 with SRV Records", draft-ietf-dane-srv-06 (work in 1029 progress), June 2014. 1031 [I-D.ietf-tls-downgrade-scsv] 1032 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1033 Suite Value (SCSV) for Preventing Protocol Downgrade 1034 Attacks", draft-ietf-tls-downgrade-scsv-02 (work in 1035 progress), November 2014. 1037 [I-D.ietf-tls-session-hash] 1038 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1039 A., and M. Ray, "Transport Layer Security (TLS) Session 1040 Hash and Extended Master Secret Extension", draft-ietf- 1041 tls-session-hash-03 (work in progress), November 2014. 1043 [I-D.ietf-tls-sslv3-diediedie] 1044 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1045 "Deprecating Secure Sockets Layer Version 3.0", draft- 1046 ietf-tls-sslv3-diediedie-00 (work in progress), December 1047 2014. 1049 [I-D.ietf-uta-xmpp] 1050 Saint-Andre, P. and a. alkemade, "Use of Transport Layer 1051 Security (TLS) in the Extensible Messaging and Presence 1052 Protocol (XMPP)", draft-ietf-uta-xmpp-05 (work in 1053 progress), January 2015. 1055 [Kleinjung2010] 1056 Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", 1057 CRYPTO 10, 2010, . 1059 [Krawczyk2001] 1060 Krawczyk, H., "The order of encryption and authentication 1061 for protecting communications (Or: how secure is SSL?)", 1062 CRYPTO 01, 2001, . 1064 [Multiple-Encryption] 1065 Merkle, R. and M. Hellman, "On the security of multiple 1066 encryption", Communications of the ACM 24, 1981, 1067 . 1069 [NIST.SP.800-56A] 1070 Barker, E., Chen, L., Roginsky, A., and M. Smid, 1071 "Recommendation for Pair-Wise Key Establishment Schemes 1072 Using Discrete Logarithm Cryptography", NIST Special 1073 Publication 800-56A, 2013, . 1076 [POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE 1077 Bites: Exploiting the SSL 3.0 Fallback", 2014, . 1080 [PatersonRS11] 1081 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size 1082 does matter: attacks and proofs for the TLS record 1083 protocol", 2011, 1084 . 1086 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1087 RFC 2246, January 1999. 1089 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1090 Algorithm and Its Use with IPsec", RFC 3602, September 1091 2003. 1093 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1094 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1096 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1097 Security", RFC 4347, April 2006. 1099 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1100 "Transport Layer Security (TLS) Session Resumption without 1101 Server-Side State", RFC 5077, January 2008. 1103 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1104 Encryption", RFC 5116, January 2008. 1106 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1107 Housley, R., and W. Polk, "Internet X.509 Public Key 1108 Infrastructure Certificate and Certificate Revocation List 1109 (CRL) Profile", RFC 5280, May 2008. 1111 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1112 Curve Cryptography Algorithms", RFC 6090, February 2011. 1114 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1115 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1116 August 2011. 1118 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1119 Protocol (XMPP): Core", RFC 6120, March 2011. 1121 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 1122 Layer Security (TLS)", RFC 6460, January 2012. 1124 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1125 of Named Entities (DANE) Transport Layer Security (TLS) 1126 Protocol: TLSA", RFC 6698, August 2012. 1128 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1129 Transport Security (HSTS)", RFC 6797, November 2012. 1131 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1132 Galperin, S., and C. Adams, "X.509 Internet Public Key 1133 Infrastructure Online Certificate Status Protocol - OCSP", 1134 RFC 6960, June 2013. 1136 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1137 Multiple Certificate Status Request Extension", RFC 6961, 1138 June 2013. 1140 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 1141 Tests for the Internet Key Exchange Protocol Version 2 1142 (IKEv2)", RFC 6989, July 2013. 1144 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1145 Most of the Time", RFC 7435, December 2014. 1147 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1148 Known Attacks on Transport Layer Security (TLS) and 1149 Datagram TLS (DTLS)", RFC 7457, February 2015. 1151 [Smith2013] 1152 Smith, B., "Proposal to Change the Default TLS 1153 Ciphersuites Offered by Browsers.", 2013, . 1156 [Soghoian2011] 1157 Soghoian, C. and S. Stamm, "Certified lies: Detecting and 1158 defeating government interception attacks against SSL.", 1159 Proc. 15th Int. Conf. Financial Cryptography and Data 1160 Security , 2011. 1162 [triple-handshake] 1163 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 1164 "Triple Handshakes Considered Harmful: Breaking and Fixing 1165 Authentication over TLS", 2014, . 1168 Appendix A. Change Log 1170 Note to RFC Editor: please remove this section before publication. 1172 A.1. draft-ietf-uta-tls-bcp-08 1174 o More WGLC feedback. 1176 o TLS 1.1 is now SHOULD NOT, just like TLS 1.0. 1178 o SHOULD NOT use curves of less than 192 bits for ECDH. 1180 o Clarification regarding OCSP and OSCP stapling. 1182 A.2. draft-ietf-uta-tls-bcp-07 1184 o WGLC feedback. 1186 A.3. draft-ietf-uta-tls-bcp-06 1188 o Undo unauthenticated TLS, following another long thread on the 1189 list. 1191 A.4. draft-ietf-uta-tls-bcp-05 1193 o Lots of comments by Sean Turner. 1195 o Unauthenticated TLS, following a long thread on the list. 1197 A.5. draft-ietf-uta-tls-bcp-04 1199 o Some cleanup, and input from TLS WG discussion on applicability. 1201 A.6. draft-ietf-uta-tls-bcp-03 1203 o Disallow truncated HMAC. 1205 o Applicability to DTLS. 1207 o Some more text restructuring. 1209 o Host name validation is sometimes irrelevant. 1211 o HSTS: MUST implement, SHOULD deploy. 1213 o Session identities are not protected, only tickets are. 1215 o Clarified the target audience. 1217 A.7. draft-ietf-uta-tls-bcp-02 1219 o Rearranged some sections for clarity and re-styled the text so 1220 that normative text is followed by rationale where possible. 1222 o Removed the recommendation to use Brainpool curves. 1224 o Triple Handshake mitigation. 1226 o MUST NOT negotiate algorithms lower than 112 bits of security. 1228 o MUST implement SNI, but use per local policy. 1230 o Changed SHOULD NOT negotiate or fall back to SSLv3 to MUST NOT. 1232 o Added hostname validation. 1234 o Non-normative discussion of DH exponent reuse. 1236 A.8. draft-ietf-tls-bcp-01 1238 o Clarified that specific TLS-using protocols may have stricter 1239 requirements. 1241 o Changed TLS 1.0 from MAY to SHOULD NOT. 1243 o Added discussion of "optional TLS" and HSTS. 1245 o Recommended use of the Signature Algorithm and Renegotiation Info 1246 extensions. 1248 o Use of a strong cipher for a resumption ticket: changed SHOULD to 1249 MUST. 1251 o Added an informational discussion of certificate revocation, but 1252 no recommendations. 1254 A.9. draft-ietf-tls-bcp-00 1256 o Initial WG version, with only updated references. 1258 A.10. draft-sheffer-tls-bcp-02 1260 o Reorganized the content to focus on recommendations. 1262 o Moved description of attacks to a separate document (draft- 1263 sheffer-uta-tls-attacks). 1265 o Strengthened recommendations regarding session resumption. 1267 A.11. draft-sheffer-tls-bcp-01 1269 o Clarified our motivation in the introduction. 1271 o Added a section justifying the need for forward secrecy. 1273 o Added recommendations for RSA and DH parameter lengths. Moved 1274 from DHE to ECDHE, with a discussion on whether/when DHE is 1275 appropriate. 1277 o Recommendation to avoid fallback to SSLv3. 1279 o Initial information about browser support - more still needed! 1281 o More clarity on compression. 1283 o Client can offer stronger cipher suites. 1285 o Discussion of the regular TLS mandatory cipher suite. 1287 A.12. draft-sheffer-tls-bcp-00 1289 o Initial version. 1291 Authors' Addresses 1293 Yaron Sheffer 1294 Intuit 1295 4 HaHarash St. 1296 Hod HaSharon 4524075 1297 Israel 1299 Email: yaronf.ietf@gmail.com 1301 Ralph Holz 1302 Technische Universitaet Muenchen 1303 Boltzmannstr. 3 1304 Garching 85748 1305 Germany 1307 Email: ralph.ietf@gmail.com 1309 Peter Saint-Andre 1310 &yet 1312 Email: peter@andyet.com 1313 URI: https://andyet.com/