idnits 2.17.1 draft-ietf-uta-tls-bcp-07.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 (November 11, 2014) is 3453 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) ** 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 (-05) exists of draft-farrelll-mpls-opportunistic-encrypt-02 == 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-uta-tls-attacks-04 -- 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: 5 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: Best Current Practice R. Holz 5 Expires: May 15, 2015 TUM 6 P. Saint-Andre 7 &yet 8 November 11, 2014 10 Recommendations for Secure Use of TLS and DTLS 11 draft-ietf-uta-tls-bcp-07 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 modes 20 of operation. This document provides recommendations for improving 21 the security of deployed services that use TLS and DTLS. The 22 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 May 15, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 5 65 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 7 68 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 9 73 4.2.1. Implementation Details . . . . . . . . . . . . . . . 10 74 4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 10 75 4.4. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 11 76 4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 12 77 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 12 78 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 12 79 5.2. Unauthenticated TLS and Opportunistic Encryption . . . . 13 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 14 83 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 15 85 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 16 86 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 17 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 9.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 92 A.1. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 21 93 A.2. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 21 94 A.3. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 21 95 A.4. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 22 96 A.5. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 22 97 A.6. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 22 98 A.7. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 22 99 A.8. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 23 100 A.9. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 23 101 A.10. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 23 102 A.11. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Introduction 107 Transport Layer Security (TLS) [RFC5246] and Datagram Transport 108 Security Layer (DTLS) [RFC6347] are widely used to protect data 109 exchanged over application protocols such as HTTP, SMTP, IMAP, POP, 110 SIP, and XMPP. Over the last few years, several serious attacks on 111 TLS have emerged, including attacks on its most commonly used cipher 112 suites and modes of operation. For instance, both the AES-CBC 113 [RFC3602] and RC4 [I-D.ietf-tls-prohibiting-rc4] encryption 114 algorithms, which together are the most widely deployed ciphers, have 115 been attacked in the context of TLS. A companion document 116 [I-D.ietf-uta-tls-attacks] provides detailed information about these 117 attacks. 119 Because of these attacks, those who implement and deploy TLS and DTLS 120 need updated guidance on how TLS can be used securely. This document 121 provides guidance for deployed services as well as for software 122 implementations, assuming the implementer expects his or her code to 123 be deployed in environments defined in the following section. In 124 fact, this document calls for the deployment of algorithms that are 125 widely implemented but not yet widely deployed. Concerning 126 deployment, this document targets a wide audience, namely all 127 deployers who wish to add authentication (be it one-way only or 128 mutual), confidentiality, and data integrity protection to their 129 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 will have fewer vulnerabilities than TLS 1.2 or below. This 141 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. 153 Community knowledge about the strength of various algorithms and 154 feasible attacks can change quickly, and experience shows that a 155 security BCP is a point-in-time statement. Readers are advised to 156 seek out any errata or updates that apply to this document. 158 2. Terminology 160 A number of security-related terms in this document are used in the 161 sense defined in [RFC4949]. 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 3. General Recommendations 169 This section provides general recommendations on the secure use of 170 TLS. Recommendations related to cipher suites are discussed in the 171 following section. 173 3.1. Protocol Versions 175 3.1.1. SSL/TLS Protocol Versions 177 It is important both to stop using old, less secure versions of SSL/ 178 TLS and to start using modern, more secure versions; therefore, the 179 following are the recommendations concerning TLS/SSL protocol 180 versions: 182 o Implementations MUST NOT negotiate SSL version 2. 184 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 186 o Implementations MUST NOT negotiate SSL version 3. 188 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 189 plugged some significant security holes, but did not support 190 strong cipher suites. SSLv3 does not support TLS extensions, some 191 of which (e.g., renegotiation_info) are security-critical. In 192 addition, with the emergence of the POODLE attack [POODLE], SSLv3 193 is now widely recognized as fundamentally insecure. 195 o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]. 197 Rationale: TLS 1.0 (published in 1999) does not support many 198 modern, strong cipher suites. 200 o Implementations MAY negotiate TLS version 1.1 [RFC4346]. 202 Rationale: TLS 1.1 (published in 2006) is a security improvement 203 over TLS 1.0, but still does not support certain stronger cipher 204 suites. 206 o Implementations MUST support, and prefer to negotiate, TLS version 207 1.2 [RFC5246]. 209 Rationale: Several stronger cipher suites are available only with 210 TLS 1.2 (published in 2008). In fact, the cipher suites 211 recommended by this document (Section 4.2 below) are only 212 available in TLS 1.2. 214 This BCP applies to TLS 1.2. It is not safe for readers to assume 215 that the recommendations in this BCP apply to any future version of 216 TLS. 218 3.1.2. DTLS Protocol Versions 220 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 221 1.1 was published. The following are the recommendations with 222 respect to DTLS: 224 o Implementations MAY negotiate DTLS version 1.0 [RFC4347]. 226 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 228 o Implementations MUST support, and prefer to negotiate, DTLS 229 version 1.2 [RFC6347]. 231 Version 1.2 of DTLS correlates to Version 1.2 of TLS 1.2 (see 232 above). (There is no Version 1.1 of DTLS.) 234 3.1.3. Fallback to Lower Versions 236 Clients that "fallback" to lower versions of the protocol after the 237 server rejects higher versions of the protocol MUST NOT fallback to 238 SSLv3. 240 Rationale: Some client implementations revert to lower versions of 241 TLS or even to SSLv3 if the server rejected higher versions of the 242 protocol. This fallback can be forced by a man in the middle (MITM) 243 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 244 1.2, the version recommended by this document. While TLS 1.0-only 245 servers are still quite common, IP scans show that SSLv3-only servers 246 amount to only about 3% of the current Web server population. 248 3.2. Strict TLS 250 To prevent SSL Stripping: 252 o In cases where an application protocol allows implementations or 253 deployments a choice between strict TLS configuration and dynamic 254 upgrade from unencrypted to TLS-protected traffic (such as 255 STARTTLS), clients and servers SHOULD prefer strict TLS 256 configuration. 258 o In many application protocols, clients can be configured to use 259 TLS no matter whether the server offers TLS during a protocol 260 exchange or advertises support for TLS (e.g., through a flag 261 indicating that TLS is required). Application clients SHOULD use 262 TLS by default, and disable this default only through explicit 263 configuration by the user. 265 o HTTP client and server implementations MUST support the HTTP 266 Strict Transport Security (HSTS) header [RFC6797], in order to 267 allow Web servers to advertise that they are willing to accept 268 TLS-only clients. 270 o When applicable, Web servers SHOULD use HSTS to indicate that they 271 are willing to accept TLS-only clients. 273 Rationale: Combining unprotected and TLS-protected communication 274 opens the way to SSL Stripping and similar attacks, since an initial 275 part of the communication is not integrity protected and therefore 276 can be manipulated by an attacker whose goal is to keep the 277 communication in the clear. 279 3.3. Compression 281 Implementations and deployments SHOULD disable TLS-level compression 282 ([RFC5246], Section 6.2.2). 284 Rationale: TLS compression has been subject to security attacks, such 285 as the CRIME attack. 287 Implementers should note that compression at higher protocol levels 288 can allow an active attacker to extract cleartext information from 289 the connection. The BREACH attack is one such case. These issues 290 can only be mitigated outside of TLS and are thus out of scope of the 291 current document. See Section 2.5 of [I-D.ietf-uta-tls-attacks] for 292 further details. 294 3.4. TLS Session Resumption 296 If TLS session resumption is used, care ought to be taken to do so 297 safely. In particular, when using session tickets [RFC5077], the 298 resumption information MUST be authenticated and encrypted to prevent 299 modification or eavesdropping by an attacker. Further 300 recommendations apply to session tickets: 302 o A strong cipher suite MUST be used when encrypting the ticket (as 303 least as strong as the main TLS cipher suite). 305 o Ticket keys MUST be changed regularly, e.g., once every week, so 306 as not to negate the benefits of forward secrecy (see Section 7.3 307 for details on forward secrecy). 309 o Session ticket validity SHOULD be limited to a reasonable duration 310 (e.g., 1 day), for similar reasons. 312 Rationale: session resumption is another kind of TLS handshake, and 313 therefore must be as secure as the initial handshake. This document 314 (Section 4) recommends the use of cipher suites that provide forward 315 secrecy, i.e. that prevent an attacker who gains momentary access to 316 the TLS endpoint (either client or server) and its secrets from 317 reading either past or future communication. The tickets must be 318 managed so as not to negate this security property. 320 3.5. TLS Renegotiation 322 Where handshake renegotiation is implemented, both clients and 323 servers MUST implement the renegotiation_info extension, as defined 324 in [RFC5746]. 326 To counter the Triple Handshake attack, we adopt the recommendation 327 from [triple-handshake]: TLS clients SHOULD ensure that all 328 certificates received over a connection are valid for the current 329 server endpoint, and abort the handshake if they are not. In some 330 usages, it may be simplest to refuse any change of certificates 331 during renegotiation. 333 3.6. Server Name Indication 335 TLS implementations MUST support the Server Name Indication (SNI) 336 extension for those higher level protocols which would benefit from 337 it, including HTTPS. However, unlike implementation, the use of SNI 338 in particular circumstances is a matter of local policy. 340 Rationale: SNI supports deployment of multiple TLS-protected virtual 341 servers on a single address, and therefore enables fine-grained 342 security for these virtual servers, by allowing each one to have its 343 own certificate. 345 4. Recommendations: Cipher Suites 347 TLS and its implementations provide considerable flexibility in the 348 selection of cipher suites. Unfortunately, some available cipher 349 suites are insecure, some do not provide the targeted security 350 services, and some no longer provide enough security. Incorrectly 351 configuring a server leads to no or reduced security. This section 352 includes recommendations on the selection and negotiation of cipher 353 suites. 355 4.1. General Guidelines 357 Cryptographic algorithms weaken over time as cryptanalysis improves. 358 In other words, as time progresses, algorithms that were once 359 considered strong but are now weak, need to be phased out over time 360 and replaced with more secure cipher suites to ensure that desired 361 security properties still hold. SSL/TLS has been in existence for 362 almost 20 years at this point and this section provides some much 363 needed recommendations concerning cipher suite selection: 365 o Implementations MUST NOT negotiate the cipher suites with NULL 366 encryption. 368 Rationale: The NULL cipher suites do not encrypt traffic and so 369 provide no confidentiality services. Any entity in the network 370 with access to the connection can view the plaintext of contents 371 being exchanged by the client and server. 373 o Implementations MUST NOT negotiate RC4 cipher suites. 375 Rationale: The RC4 stream cipher has a variety of cryptographic 376 weaknesses, as documented in [I-D.ietf-tls-prohibiting-rc4]. We 377 note that this guideline does not apply to DTLS, which 378 specifically forbids the use of RC4. 380 o Implementations MUST NOT negotiate cipher suites offering less 381 than 112 bits of security, including the so-called "export-level" 382 encryption (which provide 40 or 56 bits of security). 384 Rationale: Based on [RFC3766], at least 112 bits of security is 385 needed. 40-bit and 56-bit security are considered insecure today. 386 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. 388 o Implementations SHOULD NOT negotiate cipher suites that use 389 algorithms offering less than 128 bits of security. 391 Rationale: Cipher suites that offer between 112-bits and 128-bits 392 of security are not considered weak at this time, however it is 393 expected that their useful lifespan is short enough to justify 394 supporting stronger cipher suites at this time. 128-bit ciphers 395 are expected to remain secure for at least several years, and 396 256-bit ciphers "until the next fundamental technology 397 breakthrough". Note that some legacy cipher suites (e.g., 168-bit 398 3DES) have an effective key length which is smaller than their 399 nominal key length (112 bits in the case of 3DES). Such cipher 400 suites should be evaluated according to their effective key 401 length. 403 o Implementations MUST support, and SHOULD prefer to negotiate, 404 cipher suites offering forward secrecy, such as those in the 405 Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie- 406 Hellman ("DHE" and "ECDHE") families. 408 Rationale: Forward secrecy (sometimes called "perfect forward 409 secrecy") prevents the recovery of information that was encrypted 410 with older session keys, thus limiting the amount of time during 411 which attacks can be successful. See Section 7.3 for a detailed 412 discussion. 414 4.2. Recommended Cipher Suites 416 Given the foregoing considerations, implementation and deployment of 417 the following cipher suites is RECOMMENDED: 419 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 421 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 423 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 425 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 426 These cipher suites are supported only in TLS 1.2 since they are 427 authenticated encryption (AEAD) algorithms [RFC5116]. 429 Typically, in order to prefer these suites, the order of suites needs 430 to be explicitly configured in server software. 432 4.2.1. Implementation Details 434 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 435 first proposal to any server, unless they have prior knowledge that 436 the server cannot respond to a TLS 1.2 client_hello message. 438 Servers SHOULD prefer this cipher suite whenever it is proposed, even 439 if it is not the first proposal. 441 Clients are of course free to offer stronger cipher suites, e.g., 442 using AES-256; when they do, the server SHOULD prefer the stronger 443 cipher suite unless there are compelling reasons (e.g., seriously 444 degraded performance) to choose otherwise. 446 This document is not an application profile standard, in the sense of 447 Section 9 of [RFC5246]. As a result, clients and servers are still 448 REQUIRED to support the mandatory TLS cipher suite, 449 TLS_RSA_WITH_AES_128_CBC_SHA. 451 Note that some profiles of TLS 1.2 use different cipher suites. For 452 example, [RFC6460] defines a profile that uses the 453 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 454 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 456 [RFC4492] allows clients and servers to negotiate ECDH parameters 457 (curves). Both clients and servers SHOULD include the "Supported 458 Elliptic Curves" extension [RFC4492]. For interoperability, clients 459 and servers SHOULD support the NIST P-256 (secp256r1) curve 460 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 461 extension with a single element, "uncompressed". 463 4.3. Public Key Length 465 When using the cipher suites recommended in this document, two public 466 keys are normally used in the TLS handshake: one for the Diffie- 467 Hellman key agreement and one for server authentication. Where a 468 client certificate is used, a third public key is added. 470 With a key exchange based on modular Diffie-Hellman ("DHE" cipher 471 suites), DH key lengths of at least 2048 bits are RECOMMENDED. 473 Rationale: For various reasons, in practice DH keys are typically 474 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 475 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 476 would be roughly equivalent to only an 80-bit symmetric key 477 [RFC3766], it is better to use keys longer than that for the "DHE" 478 family of cipher suites. A DH key of 1926 bits would be roughly 479 equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048 480 bits might be sufficient for at least the next 10 years. See 481 Section 4.4 for additional information on the use of modular Diffie- 482 Hellman in TLS. 484 As noted in [RFC3766], correcting for the emergence of a TWIRL 485 machine would imply that 1024-bit DH keys yield about 65 bits of 486 equivalent strength and that a 2048-bit DH key would yield about 92 487 bits of equivalent strength. 489 Servers SHOULD authenticate using at least 2048-bit certificates. In 490 addition, the use of SHA-256 fingerprints is RECOMMENDED (see 491 [CAB-Baseline] for more details). Clients SHOULD indicate to servers 492 that they request SHA-256, by using the "Signature Algorithms" 493 extension defined in TLS 1.2. 495 4.4. Modular vs. Elliptic Curve DH Cipher Suites 497 Not all TLS implementations support both modular and EC Diffie- 498 Hellman groups, as required by Section 4.2. Some implementations are 499 severely limited in the length of DH values. When such 500 implementations need to be accommodated, we recommend using (in 501 priority order): 503 1. Elliptic Curve DHE with negotiated parameters [RFC5289] 505 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 506 Diffie-Hellman parameters 508 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters. 510 Rationale: Elliptic Curve Cryptography is not universally deployed 511 for several reasons, including its complexity compared to modular 512 arithmetic and longstanding perceptions of IPR concerns (which, for 513 the most part, have now been resolved [RFC6090]). On the other hand, 514 there are two related issues hindering effective use of modular 515 Diffie-Hellman cipher suites in TLS: 517 o There are no protocol mechanisms to negotiate the DH groups or 518 parameter lengths supported by client and server. 520 o There are widely deployed client implementations that reject 521 received DH parameters if they are longer than 1024 bits. 523 We note that with DHE and ECDHE cipher suites, the TLS master key 524 only depends on the Diffie-Hellman parameters and not on the strength 525 of the RSA certificate; moreover, 1024 bit modular DH parameters are 526 generally considered insufficient at this time. 528 With modular ephemeral DH, deployers SHOULD carefully evaluate 529 interoperability vs. security considerations when configuring their 530 TLS endpoints. 532 4.5. Truncated HMAC 534 Implementations MUST NOT use the Truncated HMAC extension, defined in 535 Section 7 of [RFC6066]. 537 Rationale: the extension does not apply to the AEAD cipher suites 538 recommended above. However it does apply to most other TLS cipher 539 suites. Its use has been shown to be insecure in [PatersonRS11]. 541 5. Applicability Statement 543 The deployment recommendations of this document address the operators 544 of application layer services that are most commonly used on the 545 Internet, including, but not limited to: 547 o Operators of web servers that wish to protect HTTP with TLS. 549 o Operators of email servers who wish to protect the application- 550 layer protocols with TLS (e.g., IMAP, POP3 or SMTP). 552 o Operators of instant-messaging services who wish to protect their 553 application-layer protocols with TLS (e.g., XMPP or IRC). 555 5.1. Security Services 557 This document provides recommendations for an audience that wishes to 558 secure their communication with TLS to achieve the following: 560 o Confidentiality: all application-layer communication is encrypted 561 with the goal that no party should be able to decrypt it except 562 the intended receiver. 564 o Data integrity: any changes made to the communication in transit 565 are detectable by the receiver. 567 o Authentication: an end-point of the TLS communication is 568 authenticated as the intended entity to communicate with. 570 With regard to authentication, TLS enables authentication of one or 571 both end-points in the communication. Although some TLS usage 572 scenarios do not require authentication, those scenarios are not in 573 scope for this document (a rationale for this decision is provided 574 under Section 5.2). 576 If deployers deviate from the recommendations given in this document, 577 they MUST verify that they do not need one of the foregoing security 578 services. 580 This document applies only to environments where confidentiality is 581 required. It recommends algorithms and configuration options that 582 enforce secrecy of the data-in-transit. 584 This document also assumes that data integrity protection is always 585 one of the goals of a deployment. In cases where integrity is not 586 required, it does not make sense to employ TLS in the first place. 587 There are attacks against confidentiality-only protection that 588 utilize the lack of integrity to also break confidentiality (see for 589 instance [DegabrieleP07] in the context of IPsec). 591 The intended audience covers those services that are most commonly 592 used on the Internet. Typically, all communication between TLS 593 clients and TLS servers requires all three of the above security 594 services. This is particularly true where TLS clients are user 595 agents like Web browsers or email software. 597 This document does not address the rarer deployment scenarios where 598 one of the above three properties is not desired, such as the use 599 case described under Section 5.2 below. Another example of an 600 audience not needing confidentiality is the following: a monitored 601 network where the authorities in charge of the respective traffic 602 domain require full access to unencrypted (plaintext) traffic, and 603 where users collaborate and send their traffic in the clear. 605 5.2. Unauthenticated TLS and Opportunistic Encryption 607 Several important applications use TLS to protect data between a TLS 608 client and a TLS server, but do so without the TLS client necessarily 609 verifying the server's certificate. This practice is often called 610 "unauthenticated TLS". The reader is referred to 611 [I-D.ietf-dane-smtp-with-dane] for an example and an explanation of 612 why this less secure practice will likely remain common in the 613 context of SMTP (especially for MTA-to-MTA communications). The 614 practice is also encountered in similar contexts such as server-to- 615 server traffic on the XMPP network (where multi-tenant hosting 616 environments make it difficult for operators to obtain proper 617 certificates for all of the domains they service). 619 Furthermore, in some scenarios the use of TLS itself is optional, 620 i.e. the client decides dynamically ("opportunistically") whether to 621 use TLS with a particular server or to connect in the clear. This 622 practice, often called "opportunistic encryption", and is described 623 at length in Section 2 of [I-D.farrelll-mpls-opportunistic-encrypt]. 625 It can be argued that the recommendations provided in this document 626 ought to apply equally to unauthenticated TLS as well as 627 authenticated TLS. That would keep TLS implementations and 628 deployments in sync, which is a desirable property given that servers 629 can be used simultaneously for unauthenticated TLS and for 630 authenticated TLS (indeed, a server cannot know whether a client 631 might attempt authenticated or unauthenticated TLS). On the other 632 hand, it has been argued that some of the recommendations in this 633 document might be too strict for unauthenticated scenarios and that 634 any security is better than no security at all (i.e., sending traffic 635 in the clear), even if it means deploying outdated protocol versions 636 and ciphers in unauthenticated scenarios. The sense of the UTA 637 Working Group was to complete work on this document about 638 authenticated TLS and to initiate work on a separate document about 639 unauthenticated TLS. 641 In summary: this document does not apply to unauthenticated TLS use 642 cases. 644 6. IANA Considerations 646 This document requests no actions of IANA. [Note to RFC Editor: 647 please remove this whole section before publication.] 649 7. Security Considerations 651 This entire document discusses the security practices directly 652 affecting applications using the TLS protocol. This section contains 653 broader security considerations related to technologies used in 654 conjunction with or by TLS. 656 7.1. Host Name Validation 658 Application authors should take note that TLS implementations 659 frequently do not validate host names and must therefore determine if 660 the TLS implementation they are using does and, if not, write their 661 own validation code or consider changing the TLS implementation. 663 It is noted that the requirements regarding host name validation (and 664 in general, binding between the TLS layer and the protocol that runs 665 above it) vary between different protocols. For HTTPS, these 666 requirements are defined by Section 3 of [RFC2818]. 668 Readers are referred to [RFC6125] for further details regarding 669 generic host name validation in the TLS context. In addition, the 670 RFC contains a long list of example protocols, some of which 671 implement a policy very different from HTTPS. 673 If the host name is discovered indirectly and in an insecure manner 674 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 675 NOT be used as a reference identifier [RFC6125] even when it matches 676 the presented certificate. This proviso does not apply if the host 677 name is discovered securely (for further discussion, see for example 678 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]). 680 Host name validation typically applies only to the leaf "end entity" 681 certificate. Naturally, in order to ensure proper authentication in 682 the context of the PKI, application clients need to verify the entire 683 certification path in accordance with [RFC5280] (see also [RFC6125]). 685 7.2. AES-GCM 687 Section 4.2 above recommends the use of the AES-GCM authenticated 688 encryption algorithm. Please refer to [RFC5246], Section 11 for 689 general security considerations when using TLS 1.2, and to [RFC5288], 690 Section 6 for security considerations that apply specifically to AES- 691 GCM when used with TLS. 693 7.3. Forward Secrecy 695 Forward secrecy (also often called Perfect Forward Secrecy or "PFS" 696 and defined in [RFC4949]) is a defense against an attacker who 697 records encrypted conversations where the session keys are only 698 encrypted with the communicating parties' long-term keys. Should the 699 attacker be able to obtain these long-term keys at some point later 700 in time, he will be able to decrypt the session keys and thus the 701 entire conversation. In the context of TLS and DTLS, such compromise 702 of long-term keys is not entirely implausible. It can happen, for 703 example, due to: 705 o A client or server being attacked by some other attack vector, and 706 the private key retrieved. 708 o A long-term key retrieved from a device that has been sold or 709 otherwise decommissioned without prior wiping. 711 o A long-term key used on a device as a default key [Heninger2012]. 713 o A key generated by a Trusted Third Party like a CA, and later 714 retrieved from it either by extortion or compromise 715 [Soghoian2011]. 717 o A cryptographic break-through, or the use of asymmetric keys with 718 insufficient length [Kleinjung2010]. 720 Forward secrecy ensures in such cases that the session keys cannot be 721 determined even by an attacker who obtains the long-term keys some 722 time after the conversation. It also protects against an attacker 723 who is in possession of the long-term keys, but remains passive 724 during the conversation. 726 Forward secrecy is generally achieved by using the Diffie-Hellman 727 scheme to derive session keys. The Diffie-Hellman scheme has both 728 parties maintain private secrets and send parameters over the network 729 as modular powers over certain cyclic groups. The properties of the 730 so-called Discrete Logarithm Problem (DLP) allow to derive the 731 session keys without an eavesdropper being able to do so. There is 732 currently no known attack against DLP if sufficiently large 733 parameters are chosen. A variant of the Diffie-Hellman scheme uses 734 Elliptic Curves instead of the originally proposed modular 735 arithmetics. 737 Unfortunately, many TLS/DTLS cipher suites were defined that do not 738 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. We 739 thus advocate strict use of forward-secrecy-only ciphers. 741 7.4. Diffie-Hellman Exponent Reuse 743 For performance reasons, many TLS implementations reuse Diffie- 744 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 745 connections. Such reuse can result in major security issues: 747 o If exponents are reused for a long time (e.g., more than a few 748 hours), an attacker who gains access to the host can decrypt 749 previous connections. In other words, exponent reuse negates the 750 effects of forward secrecy. 752 o TLS implementations that reuse exponents should test the DH public 753 key they receive for group membership, in order to avoid some 754 known attacks. These tests are not standardized in TLS at the 755 time of writing. See [RFC6989] for recipient tests required of 756 IKEv2 implementations that reuse DH exponents. 758 7.5. Certificate Revocation 760 Unfortunately, no mechanism exists at this time that we can recommend 761 as a complete and efficient solution for the problem of checking the 762 revocation status of common public key certificates (a.k.a. PKIX 763 certificates, [RFC5280]). The current state of the art is as 764 follows: 766 o Certificate Revocation Lists (CRLs) are not scalable and therefore 767 rarely used. 769 o The On-Line Certification Status Protocol (OCSP) presents both 770 scaling and privacy issues when used for heavy traffic Web 771 servers. In addition, clients typically "soft-fail", meaning they 772 do not abort the TLS connection if the OCSP server does not 773 respond. 775 o OCSP stapling (Section 8 of [RFC6066]) resolves the operational 776 issues with OCSP, but is still ineffective in the presence of a 777 MITM attacker because the attacker can simply ignore the client's 778 request for a stapled OCSP response. 780 o OCSP stapling as defined in [RFC6066] does not extend to 781 intermediate certificates used in a certificate chain. [RFC6961] 782 addresses this shortcoming, but is a recent addition without much 783 deployment. 785 o Proprietary mechanisms that embed revocation lists in the Web 786 browser's configuration database cannot scale beyond a small 787 number of the most heavily used Web servers. 789 With regard to PKIX certificates, servers SHOULD support OCSP and 790 OCSP stapling, including the OCSP stapling extension defined in 791 [RFC6961], as a best practice given the current state of the art and 792 as a foundation for a possible future solution. 794 The foregoing considerations do not apply to scenarios where the 795 DANE-TLSA resource record [RFC6698] is used to signal to a client 796 which certificate a server considers valid and good to use for TLS 797 connections. 799 8. Acknowledgments 801 We would like to thank Uri Blumenthal, Viktor Dukhovni, Stephen 802 Farrell, Paul Hoffman, Simon Josefsson, Watson Ladd, Orit Levin, 803 Ilari Liusvaara, Johannes Merkle, Bodo Moeller, Yoav Nir, Kenny 804 Paterson, Patrick Pelletier, Tom Ritter, Rich Salz, Sean Turner, and 805 Aaron Zauner for their feedback and suggested improvements. Thanks 806 to Brian Smith, whose "browser cipher suites" page is a great 807 resource. Finally, thanks to all others who commented on the TLS, 808 UTA, and other discussion lists but who are not mentioned here by 809 name. 811 9. References 813 9.1. Normative References 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 820 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 821 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 822 RFC 3766, April 2004. 824 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 825 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 826 for Transport Layer Security (TLS)", RFC 4492, May 2006. 828 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 829 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 831 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 832 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 833 August 2008. 835 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 836 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 837 August 2008. 839 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 840 "Transport Layer Security (TLS) Renegotiation Indication 841 Extension", RFC 5746, February 2010. 843 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 844 Verification of Domain-Based Application Service Identity 845 within Internet Public Key Infrastructure Using X.509 846 (PKIX) Certificates in the Context of Transport Layer 847 Security (TLS)", RFC 6125, March 2011. 849 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 850 (SSL) Version 2.0", RFC 6176, March 2011. 852 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 853 Security Version 1.2", RFC 6347, January 2012. 855 9.2. Informative References 857 [CAB-Baseline] 858 CA/Browser Forum, , "Baseline Requirements for the 859 Issuance and Management of Publicly-Trusted Certificates 860 Version 1.1.6", 2013, . 863 [DegabrieleP07] 864 Degabriele, J. and K. Paterson, "Attacking the IPsec 865 standards in encryption-only configurations", 2007, 866 . 868 [Heninger2012] 869 Heninger, N., Durumeric, Z., Wustrow, E., and J. 870 Halderman, "Mining Your Ps and Qs: Detection of Widespread 871 Weak Keys in Network Devices", Usenix Security Symposium 872 2012, 2012. 874 [I-D.farrelll-mpls-opportunistic-encrypt] 875 Farrel, A. and S. Farrell, "Opportunistic Encryption in 876 MPLS Networks", draft-farrelll-mpls-opportunistic- 877 encrypt-02 (work in progress), February 2014. 879 [I-D.ietf-dane-smtp-with-dane] 880 Dukhovni, V. and W. Hardaker, "SMTP security via 881 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 882 (work in progress), May 2014. 884 [I-D.ietf-dane-srv] 885 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 886 Based Authentication of Named Entities (DANE) TLSA Records 887 with SRV Records", draft-ietf-dane-srv-06 (work in 888 progress), June 2014. 890 [I-D.ietf-tls-prohibiting-rc4] 891 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 892 tls-prohibiting-rc4-01 (work in progress), October 2014. 894 [I-D.ietf-uta-tls-attacks] 895 Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 896 Current Attacks on TLS and DTLS", draft-ietf-uta-tls- 897 attacks-04 (work in progress), September 2014. 899 [Kleinjung2010] 900 Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", 901 CRYPTO 10, 2010, . 903 [POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE 904 Bites: Exploiting the SSL 3.0 Fallback", 2014, . 907 [PatersonRS11] 908 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size 909 does matter: attacks and proofs for the TLS record 910 protocol", 2011, 911 . 913 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 914 RFC 2246, January 1999. 916 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 917 Algorithm and Its Use with IPsec", RFC 3602, September 918 2003. 920 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 921 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 923 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 924 Security", RFC 4347, April 2006. 926 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 927 4949, August 2007. 929 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 930 "Transport Layer Security (TLS) Session Resumption without 931 Server-Side State", RFC 5077, January 2008. 933 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 934 Encryption", RFC 5116, January 2008. 936 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 937 Housley, R., and W. Polk, "Internet X.509 Public Key 938 Infrastructure Certificate and Certificate Revocation List 939 (CRL) Profile", RFC 5280, May 2008. 941 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 942 Extension Definitions", RFC 6066, January 2011. 944 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 945 Curve Cryptography Algorithms", RFC 6090, February 2011. 947 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 948 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 949 August 2011. 951 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 952 Layer Security (TLS)", RFC 6460, January 2012. 954 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 955 of Named Entities (DANE) Transport Layer Security (TLS) 956 Protocol: TLSA", RFC 6698, August 2012. 958 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 959 Transport Security (HSTS)", RFC 6797, November 2012. 961 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 962 Multiple Certificate Status Request Extension", RFC 6961, 963 June 2013. 965 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 966 Tests for the Internet Key Exchange Protocol Version 2 967 (IKEv2)", RFC 6989, July 2013. 969 [Soghoian2011] 970 Soghoian, C. and S. Stamm, "Certified lies: Detecting and 971 defeating government interception attacks against SSL.", 972 Proc. 15th Int. Conf. Financial Cryptography and Data 973 Security , 2011. 975 [triple-handshake] 976 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 977 "Triple Handshakes Considered Harmful: Breaking and Fixing 978 Authentication over TLS", 2014, . 981 Appendix A. Change Log 983 Note to RFC Editor: please remove this section before publication. 985 A.1. draft-ietf-uta-tls-bcp-07 987 o WGLC feedback. 989 A.2. draft-ietf-uta-tls-bcp-06 991 o Undo unauthenticated TLS, following another long thread on the 992 list. 994 A.3. draft-ietf-uta-tls-bcp-05 996 o Lots of comments by Sean Turner. 998 o Unauthenticated TLS, following a long thread on the list. 1000 A.4. draft-ietf-uta-tls-bcp-04 1002 o Some cleanup, and input from TLS WG discussion on applicability. 1004 A.5. draft-ietf-uta-tls-bcp-03 1006 o Disallow truncated HMAC. 1008 o Applicability to DTLS. 1010 o Some more text restructuring. 1012 o Host name validation is sometimes irrelevant. 1014 o HSTS: MUST implement, SHOULD deploy. 1016 o Session identities are not protected, only tickets are. 1018 o Clarified the target audience. 1020 A.6. draft-ietf-uta-tls-bcp-02 1022 o Rearranged some sections for clarity and re-styled the text so 1023 that normative text is followed by rationale where possible. 1025 o Removed the recommendation to use Brainpool curves. 1027 o Triple Handshake mitigation. 1029 o MUST NOT negotiate algorithms lower than 112 bits of security. 1031 o MUST implement SNI, but use per local policy. 1033 o Changed SHOULD NOT negotiate or fall back to SSLv3 to MUST NOT. 1035 o Added hostname validation. 1037 o Non-normative discussion of DH exponent reuse. 1039 A.7. draft-ietf-tls-bcp-01 1041 o Clarified that specific TLS-using protocols may have stricter 1042 requirements. 1044 o Changed TLS 1.0 from MAY to SHOULD NOT. 1046 o Added discussion of "optional TLS" and HSTS. 1048 o Recommended use of the Signature Algorithm and Renegotiation Info 1049 extensions. 1051 o Use of a strong cipher for a resumption ticket: changed SHOULD to 1052 MUST. 1054 o Added an informational discussion of certificate revocation, but 1055 no recommendations. 1057 A.8. draft-ietf-tls-bcp-00 1059 o Initial WG version, with only updated references. 1061 A.9. draft-sheffer-tls-bcp-02 1063 o Reorganized the content to focus on recommendations. 1065 o Moved description of attacks to a separate document (draft- 1066 sheffer-uta-tls-attacks). 1068 o Strengthened recommendations regarding session resumption. 1070 A.10. draft-sheffer-tls-bcp-01 1072 o Clarified our motivation in the introduction. 1074 o Added a section justifying the need for forward secrecy. 1076 o Added recommendations for RSA and DH parameter lengths. Moved 1077 from DHE to ECDHE, with a discussion on whether/when DHE is 1078 appropriate. 1080 o Recommendation to avoid fallback to SSLv3. 1082 o Initial information about browser support - more still needed! 1084 o More clarity on compression. 1086 o Client can offer stronger cipher suites. 1088 o Discussion of the regular TLS mandatory cipher suite. 1090 A.11. draft-sheffer-tls-bcp-00 1092 o Initial version. 1094 Authors' Addresses 1096 Yaron Sheffer 1097 Porticor 1098 29 HaHarash St. 1099 Hod HaSharon 4501303 1100 Israel 1102 Email: yaronf.ietf@gmail.com 1104 Ralph Holz 1105 Technische Universitaet Muenchen 1106 Boltzmannstr. 3 1107 Garching 85748 1108 Germany 1110 Email: ralph.ietf@gmail.com 1112 Peter Saint-Andre 1113 &yet 1115 Email: peter@andyet.com 1116 URI: https://andyet.com/