idnits 2.17.1 draft-ietf-uta-tls-bcp-05.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 (October 14, 2014) is 3481 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 (-14) exists of draft-ietf-dane-srv-07 == Outdated reference: A later version (-01) exists of draft-ietf-tls-prohibiting-rc4-00 == 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: April 17, 2015 TUM 6 P. Saint-Andre 7 &yet 8 October 14, 2014 10 Recommendations for Secure Use of TLS and DTLS 11 draft-ietf-uta-tls-bcp-05 13 Abstract 15 Transport Layer Security (TLS) and Datagram Transport Security Layer 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 April 17, 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. Intended Audience and Applicability Statement . . . . . . . . 4 60 2.1. Security Services . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Unauthenticated TLS . . . . . . . . . . . . . . . . . . . 5 62 3. Conventions used in this document . . . . . . . . . . . . . . 5 63 4. General Recommendations . . . . . . . . . . . . . . . . . . . 6 64 4.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 6 65 4.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 6 66 4.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 7 67 4.1.3. Fallback to Earlier Versions . . . . . . . . . . . . 7 68 4.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8 71 4.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9 72 4.6. Server Name Indication . . . . . . . . . . . . . . . . . 9 73 5. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 9 74 5.1. General Guidelines . . . . . . . . . . . . . . . . . . . 10 75 5.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 11 76 5.3. Cipher Suite Negotiation Details . . . . . . . . . . . . 11 77 5.4. Public Key Length . . . . . . . . . . . . . . . . . . . . 12 78 5.5. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 12 79 5.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 13 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 14 83 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 14 85 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 15 86 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 16 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 90 9.2. Informative References . . . . . . . . . . . . . . . . . 17 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 92 A.1. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 20 93 A.2. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 20 94 A.3. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 20 95 A.4. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 20 96 A.5. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 21 97 A.6. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 21 98 A.7. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 21 99 A.8. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 21 100 A.9. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 Transport Layer Security (TLS) and Datagram Transport Security Layer 106 (DTLS) are widely used to protect data exchanged over application 107 protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the 108 last few years, several serious attacks on TLS have emerged, 109 including attacks on its most commonly used cipher suites and modes 110 of operation. For instance, both the AES-CBC and RC4 encryption 111 algorithms, which together comprise most current usage, have been 112 attacked in the context of TLS. A companion document 113 [I-D.ietf-uta-tls-attacks] provides detailed information about these 114 attacks. 116 Because of these attacks, those who implement and deploy TLS and DTLS 117 need updated guidance on how TLS can be used securely. Note that 118 this document provides guidance for deployed services as well as 119 software implementations, assuming the implementer expects his or her 120 code to be deployed in environments defined in the following section. 121 In fact, this document calls for the deployment of algorithms that 122 are widely implemented but not yet widely deployed. Concerning 123 deployment, this document targets a wide audience, namely all 124 deployers who wish to add confidentiality and data integrity 125 protection to their communications. In many (but not all) cases 126 authentication is also desired. This document does not address the 127 rare deployment scenarios where no confidentiality is desired. 129 The recommendations herein take into consideration the security of 130 various mechanisms, their technical maturity and interoperability, 131 and their prevalence in implementations at the time of writing. 132 Unless noted otherwise, these recommendations apply to both TLS and 133 DTLS. TLS 1.3, when it is standardized and deployed in the field, 134 should resolve the current vulnerabilities while providing 135 significantly better functionality and will very likely obsolete this 136 document. 138 These are minimum recommendations for the use of TLS for the 139 specified audience. Individual specifications may have stricter 140 requirements related to one or more aspects of the protocol, based on 141 their particular circumstances. When that is the case, implementers 142 MUST adhere to those stricter requirements. 144 Community knowledge about the strength of various algorithms and 145 feasible attacks can change quickly, and experience shows that a 146 security BCP is a point-in-time statement. Readers are advised to 147 seek out any errata or updates that apply to this document. 149 2. Intended Audience and Applicability Statement 151 The deployment recommendations address the operators of application 152 layer services that are most commonly used on the Internet, 153 including, but not limited to: 155 o Operators of WWW servers that wish to protect HTTP with TLS. 157 o Operators of email servers who wish to protect the application- 158 layer protocols with TLS (e.g., IMAP, POP3 or SMTP). 160 o Operators of instant-messaging services who wish to protect their 161 application-layer protocols with TLS (e.g. XMPP or IRC). 163 2.1. Security Services 165 This document provides recommendations for an audience that wishes to 166 secure their communication with TLS to achieve the following: 168 o Confidentiality: all (payload) communication is encrypted with the 169 goal that no party should be able to decrypt it except the 170 intended receiver. 172 o Data integrity: any changes made to the communication in transit 173 are detectable by the receiver. 175 o Authentication: this means that an end-point of the TLS 176 communication is authenticated as the intended entity to 177 communicate with. TLS allows to authenticate one or both end- 178 points in the communication. Some TLS usage scenarios do not 179 require authentication, and are further discussed in Section 2.2. 181 Deployers MUST verify that they do not need one of the above security 182 services if they deviate from the recommendations given in this 183 document. 185 This document applies only to environments where confidentiality is 186 required. It recommends algorithms and configuration options that 187 enforce secrecy of the data-in-transit. While this includes the 188 majority of the TLS use cases, there are some notable exceptions. 190 This document assumes that data integrity protection is always one of 191 the goals of a deployment. In cases when integrity is not required, 192 it does not make sense to employ TLS in the first place. There are 193 attacks against confidentiality-only protection that utilize the lack 194 of integrity to also break confidentiality (see e.g. [DegabrieleP07] 195 in the context of IPsec). 197 The intended audience covers those services that are most commonly 198 used on the Internet. Typically, all communication between clients 199 and servers requires all three of the above security services. This 200 is particularly true where clients are user agents like Web browsers 201 or email software. 203 This document does not address the rare deployment scenarios where 204 one of the above three properties is not desired, with the exception 205 of the use case described in Section 2.2 below. An example of an 206 audience not needing confidentiality is the following: a monitored 207 network where the authorities in charge of the respective traffic 208 domain require full access to unencrypted (plaintext) traffic, and 209 where users collaborate and send their traffic in the clear. 211 2.2. Unauthenticated TLS 213 Several important applications use TLS to protect data between a 214 client and a server, but do so without the client verifying the 215 server's certificate. The reader is referred to 216 [I-D.dukhovni-smtp-opportunistic-tls] for additional details and an 217 explanation why this insecure practice is still common and likely to 218 remain so for a while. 220 In many of these scenarios the actual use of TLS is optional, i.e. 221 the client decides dynamically ("opportunistically") whether to use 222 TLS with a particular server or to connect in the clear. 223 Opportunistic encryption is described at length in Sec. 2 of 224 [I-D.farrelll-mpls-opportunistic-encrypt]. 226 Despite the threat model differing from "standard" authenticated 227 usage of TLS, the recommendations in this document are applicable to 228 unauthenticated uses of TLS, with the obvious exception of peer 229 authentication. 231 3. Conventions used in this document 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [RFC2119]. 237 4. General Recommendations 239 This section provides general recommendations on the secure use of 240 TLS. Recommendations related to cipher suites are discussed in the 241 following section. 243 4.1. Protocol Versions 245 4.1.1. SSL/TLS Protocol Versions 247 It is important both to stop using old, less secure versions of SSL/ 248 TLS and to start using modern, more secure versions; therefore, the 249 following are the recommendations concerning TLS/SSL protocol 250 versions: 252 o Implementations MUST NOT negotiate SSL version 2. 254 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 256 o Implementations MUST NOT negotiate SSL version 3. 258 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 259 plugged some significant security holes, but did not support 260 strong cipher suites. In addition, SSLv3 does not support TLS 261 extensions, some of which (e.g. renegotiation_info) are security- 262 critical. 264 o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]. 266 Rationale: TLS 1.0 (published in 1999) does not support many 267 modern, strong cipher suites. 269 o Implementations MAY negotiate TLS version 1.1 [RFC4346]. 271 Rationale: TLS 1.1 (published in 2006) is a security improvement 272 over TLS 1.0, but still does not support certain stronger cipher 273 suites. 275 o Implementations MUST support, and prefer to negotiate, TLS version 276 1.2 [RFC5246]. 278 Rationale: Several stronger cipher suites are available only with 279 TLS 1.2 (published in 2008). In fact, the cipher suites 280 recommended by this document (Section 5.2 below) are only 281 available in TLS 1.2. 283 This BCP applies to TLS 1.2. It is not safe for readers to assume 284 that the recommendations in this BCP apply to any future version of 285 TLS. 287 4.1.2. DTLS Protocol Versions 289 DTLS is an adaptation of TLS for UDP datagrams. 291 The following are the recommendations with respect to DTLS: 293 o Implementations MAY negotiate DTLS version 1.0 [RFC4347]. 295 o Implementations MUST negotiate DTLS version 1.2 [RFC6347]. 297 Rationale: DTLS is an adaptation of TLS for UDP that was introduced 298 when TLS 1.1 was published. Version 1.0 correlates to TLS 1.1 and 299 Version 1.2 correlates to TLS 1.2. There is no Version 1.1. 301 Note: DTLS and TLS are nearly identical. The most notable exception 302 is that RC4, which is a stream-based bulk encryption algorithm, 303 cannot be supported by DTLS. 305 4.1.3. Fallback to Earlier Versions 307 Clients that "fallback" to lower versions of the protocol after the 308 server rejects higher versions of the protocol MUST NOT fallback to 309 SSLv3. 311 Rationale: Some client implementations revert to lower versions of 312 TLS or even to SSLv3 if the server rejected higher versions of the 313 protocol. This fallback can be forced by a man in the middle (MITM) 314 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 315 1.2, the version recommended by this document. While TLS 1.0-only 316 servers are still quite common, IP scans show that SSLv3-only servers 317 amount to only about 3% of the current Web server population. 319 4.2. Strict TLS 321 To prevent SSL Stripping: 323 o In cases where an application protocol allows implementations or 324 deployments a choice between strict TLS configuration and dynamic 325 upgrade from unencrypted to TLS-protected traffic (such as 326 STARTTLS), clients and servers SHOULD prefer strict TLS 327 configuration. 329 o In many application protocols, clients can be configured to use 330 TLS even if the server has not advertised that TLS is mandatory or 331 even supported (e.g., this is often the case in messaging 332 protocols such as IMAP and XMPP). Application clients SHOULD use 333 TLS by default, and disable this default only through explicit 334 configration by the user. 336 o HTTP client and server implementations MUST support the HTTP 337 Strict Transport Security (HSTS) header [RFC6797], in order to 338 allow Web servers to advertise that they are willing to accept 339 TLS-only clients. 341 o When applicable, Web servers SHOULD use HSTS to indicate that they 342 are willing to accept TLS-only clients. 344 Rationale: Combining unprotected and TLS-protected communication 345 opens the way to SSL Stripping and similar attacks, since an initial 346 part of the communication is not integrity protected and therefore 347 can be manipulated by an attacker whose goal is to keep the 348 communication in the clear. 350 4.3. Compression 352 Implementations and deployments SHOULD disable TLS-level compression 353 ([RFC5246], Sec. 6.2.2). 355 Rationale: TLS compression has been subject to security attacks, such 356 as the CRIME attack. 358 Implementers should note that compression at higher protocol levels 359 can allow an active attacker to extract cleartext information from 360 the connection. The BREACH attack is one such case. These issues 361 can only be mitigated outside of TLS and are thus out of scope of the 362 current document. See Sec. 2.5 of [I-D.ietf-uta-tls-attacks] for 363 further details. 365 4.4. TLS Session Resumption 367 If TLS session resumption is used, care ought to be taken to do so 368 safely. In particular, when using session tickets [RFC5077], the 369 resumption information MUST be authenticated and encrypted to prevent 370 modification or eavesdropping by an attacker. Further 371 recommendations apply to session tickets: 373 o A strong cipher suite MUST be used when encrypting the ticket (as 374 least as strong as the main TLS cipher suite). 376 o Ticket keys MUST be changed regularly, e.g. once every week, so as 377 not to negate the benefits of forward secrecy (see Section 7.3 for 378 details on forward secrecy). 380 o Session ticket validity SHOULD be limited to a reasonable duration 381 (e.g. 1 day), for similar reasons. 383 Rationale: session resumption is another kind of TLS handshake, and 384 therefore must be as secure as the initial handshake. This document 385 (Section 5) recommends the use of cipher suites that provide forward 386 secrecy, i.e. that prevent an attacker who gains momentary access to 387 the TLS endpoint (either client or server) and its secrets from 388 reading either past or future communication. The tickets must be 389 managed so as not to negate this security property. 391 4.5. TLS Renegotiation 393 Where handshake renegotiation is implemented, both clients and 394 servers MUST implement the renegotiation_info extension, as defined 395 in [RFC5746]. 397 To counter the Triple Handshake attack, we adopt the recommendation 398 from [triple-handshake]: TLS clients SHOULD ensure that all 399 certificates received over a connection are valid for the current 400 server endpoint, and abort the handshake if they are not. In some 401 usages, it may be simplest to refuse any change of certificates 402 during renegotiation. 404 4.6. Server Name Indication 406 TLS implementations MUST support the Server Name Indication (SNI) 407 extension for those higher level protocols which would benefit from 408 it, including HTTPS. However, unlike implementation, the use of SNI 409 in particular circumstances is a matter of local policy. 411 Rationale: SNI supports deployment of multiple TLS-protected virtual 412 servers on a single address, and therefore enables fine grain 413 security for these virtual servers, by allowing each one to have its 414 own certificate. 416 5. Recommendations: Cipher Suites 418 TLS and its implementations provide considerable flexibility in the 419 selection of cipher suites. Unfortunately many available cipher 420 suites are insecure, and so misconfiguration can easily result in 421 reduced security. This section includes recommendations on the 422 selection and negotiation of cipher suites. 424 5.1. General Guidelines 426 Cryptographic algorithms weaken over time as cryptanalysis improves. 427 In other words, as time progresses, algorithms that were once 428 considered strong but are now weak, need to be phased out over time 429 and replaced with more secure cipher suites to ensure that desired 430 security properties still hold. SSL/TLS has been in existence for 431 almost 20 years at this point and this section provides some much 432 needed recommendations concerning cipher suite selection: 434 o Implementations MUST NOT negotiate the cipher suites with NULL 435 encryption. 437 Rationale: The NULL cipher suites do not encrypt traffic and so 438 provide no confidentiality services. Any entity in the network 439 with access to the connection can view the plaintext of contents 440 being exchanged by the client and server. 442 o Implementations MUST NOT negotiate RC4 cipher suites. 444 Rationale: The RC4 stream cipher has a variety of cryptographic 445 weaknesses, as documented in [I-D.ietf-tls-prohibiting-rc4]. We 446 note that this guideline does not apply to DTLS, which 447 specifically forbids the use of RC4. 449 o Implementations MUST NOT negotiate cipher suites offering only so- 450 called "export-level" encryption (including algorithms with 40 451 bits or 56 bits of security). 453 Rationale: These cipher suites are deliberately "dumbed down" and 454 are very easy to break. 456 o Applications MUST NOT negotiate cipher suites of less than 112 457 bits of security. 459 o Implementations SHOULD NOT negotiate cipher suites that use 460 algorithms offering less than 128 bits of security. 462 Rationale: Cipher suites that offer between 112-bits and 128-bits 463 of security are not considered weak at this time, however it is 464 expected that their useful lifespan is short enough to justify 465 supporting stronger cipher suites at this time. 128-bit ciphers 466 are expected to remain secure for at least several years, and 467 256-bit ciphers "until the next fundamental technology 468 breakthrough". Note that some legacy cipher suites (e.g. 168-bit 469 3DES) have an effective key length which is smaller than their 470 nominal key length (112 bits in the case of 3DES). Such cipher 471 suites should be evaluated according to their effective key 472 length. 474 o Implementations MUST support, and SHOULD prefer to negotiate, 475 cipher suites offering forward secrecy, such as those in the 476 Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie- 477 Hellman ("DHE" and "ECDHE") families. 479 Rationale: Forward secrecy (sometimes called "perfect forward 480 secrecy") prevents the recovery of information that was encrypted 481 with older session keys, thus limiting the amount of time during 482 which attacks can be successful. 484 5.2. Recommended Cipher Suites 486 Given the foregoing considerations, implementation and deployment of 487 the following cipher suites is RECOMMENDED: 489 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 491 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 493 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 495 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 497 It is noted that those cipher suites are supported only in TLS 1.2 498 since they are authenticated encryption (AEAD) algorithms [RFC5116]. 500 [RFC4492] allows clients and servers to negotiate ECDH parameters 501 (curves). Both clients and servers SHOULD include the "Supported 502 Elliptic Curves" extension [RFC4492]. For interoperability, clients 503 and servers SHOULD support the NIST P-256 (secp256r1) curve 504 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 505 extension with a single element, "uncompressed". 507 5.3. Cipher Suite Negotiation Details 509 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 510 first proposal to any server, unless they have prior knowledge that 511 the server cannot respond to a TLS 1.2 client_hello message. 513 Servers SHOULD prefer this cipher suite whenever it is proposed, even 514 if it is not the first proposal. 516 Clients are of course free to offer stronger cipher suites, e.g. 517 using AES-256; when they do, the server SHOULD prefer the stronger 518 cipher suite unless there are compelling reasons (e.g., seriously 519 degraded performance) to choose otherwise. 521 Note that other profiles of TLS 1.2 exist that use different cipher 522 suites. For example, [RFC6460] defines a profile that uses the 523 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 524 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 526 This document is not an application profile standard, in the sense of 527 Sec. 9 of [RFC5246]. As a result, clients and servers are still 528 REQUIRED to support the mandatory TLS cipher suite, 529 TLS_RSA_WITH_AES_128_CBC_SHA. 531 5.4. Public Key Length 533 When using the cipher suites recommended in this document, two public 534 keys are normally used in the TLS handshake: one for the Diffie- 535 Hellman key agreement and one for server authentication. Where a 536 client certificate is used, a third one is added. 538 With a key exchange based on modular Diffie-Hellman ("DHE" cipher 539 suites), DH key lengths of at least 2048 bits are RECOMMENDED. 541 Rationale: because Diffie-Hellman keys of 1024 bits are estimated to 542 be roughly equivalent to 80-bit symmetric keys, it is better to use 543 longer keys for the "DHE" family of cipher suites. Key lengths of at 544 least 2048 bits are estimated to be roughly equivalent to 112-bit 545 symmetric keys and might be sufficient for at least the next 546 10 years. See Section 5.5 for additional information on the use of 547 modular Diffie-Hellman in TLS. 549 Servers SHOULD authenticate using 2048-bit certificates. In 550 addition, the use of SHA-256 fingerprints is RECOMMENDED (see 551 [CAB-Baseline] for more details). Clients SHOULD indicate to servers 552 that they request SHA-256, by using the "Signature Algorithms" 553 extension defined in TLS 1.2. 555 5.5. Modular vs. Elliptic Curve DH Cipher Suites 557 Not all TLS implementations support both modular and EC Diffie- 558 Hellman groups, as required by Section 5.2. Some implementations are 559 severely limited in the length of DH values. When such 560 implementations need to be accommodated, we recommend using (in 561 priority order): 563 1. Elliptic Curve DHE with negotiated parameters [RFC5289] 564 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 565 Diffie-Hellman parameters 567 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters. 569 Rationale: Elliptic Curve Cryptography is not universally deployed 570 for several reasons, including its complexity compared to modular 571 arithmetic and longstanding IPR concerns. On the other hand, there 572 are two related issues hindering effective use of modular Diffie- 573 Hellman cipher suites in TLS: 575 o There are no protocol mechanisms to negotiate the DH groups or 576 parameter lengths supported by client and server. 578 o There are widely deployed client implementations that reject 579 received DH parameters if they are longer than 1024 bits. 581 We note that with DHE and ECDHE cipher suites, the TLS master key 582 only depends on the Diffie-Hellman parameters and not on the strength 583 of the RSA certificate; moreover, 1024 bit modular DH parameters are 584 generally considered insufficient at this time. 586 With modular ephemeral DH, deployers SHOULD carefully evaluate 587 interoperability vs. security considerations when configuring their 588 TLS endpoints. 590 5.6. Truncated HMAC 592 Implementations MUST NOT use the Truncated HMAC extension, defined in 593 Sec. 7 of [RFC6066]. 595 Rationale: the extension does not apply to the AEAD cipher suites 596 recommended above. However it does apply to most other TLS cipher 597 suites. Its use has been shown to be insecure in [PatersonRS11]. 599 6. IANA Considerations 601 This document requests no actions of IANA. [Note to RFC Editor: 602 please remove this whole section before publication.] 604 7. Security Considerations 606 This entire document discusses the security practices directly 607 affecting applications using the TLS protocol. This section contains 608 broader security considerations related to technologies used in 609 conjunction with or by TLS. 611 7.1. Host Name Validation 613 Application authors should take note that TLS implementations 614 frequently do not validate host names and must therefore determine if 615 the TLS implementation they are using does and, if not, write their 616 own validation code or consider changing the TLS implementation. 618 It is noted that the requirements regarding host name validation (and 619 in general, binding between the TLS layer and the protocol that runs 620 above it) vary between different protocols. For HTTPS, these 621 requirements are defined by Sec. 3 of [RFC2818]. 623 Readers are referred to [RFC6125] for further details regarding 624 generic host name validation in the TLS context. In addition, the 625 RFC contains a long list of example protocols, some of which 626 implement a policy very different from HTTPS. 628 If the host name is discovered indirectly and in an insecure manner 629 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 630 NOT be used as a reference identifier [RFC6125] even when it matches 631 the presented certificate. This proviso does not apply if the host 632 name is discovered securely (for further discussion, see for example 633 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp]). 635 7.2. AES-GCM 637 Section 5.2 above recommends the use of the AES-GCM authenticated 638 encryption algorithm. Please refer to [RFC5246], Sec. 11 for general 639 security considerations when using TLS 1.2, and to [RFC5288], Sec. 6 640 for security considerations that apply specifically to AES-GCM when 641 used with TLS. 643 7.3. Forward Secrecy 645 Forward secrecy (also often called Perfect Forward Secrecy or "PFS" 646 and defined in [RFC4949]) is a defense against an attacker who 647 records encrypted conversations where the session keys are only 648 encrypted with the communicating parties' long-term keys. Should the 649 attacker be able to obtain these long-term keys at some point later 650 in time, he will be able to decrypt the session keys and thus the 651 entire conversation. In the context of TLS and DTLS, such compromise 652 of long-term keys is not entirely implausible. It can happen, for 653 example, due to: 655 o A client or server being attacked by some other attack vector, and 656 the private key retrieved. 658 o A long-term key retrieved from a device that has been sold or 659 otherwise decommissioned without prior wiping. 661 o A long-term key used on a device as a default key [Heninger2012]. 663 o A key generated by a Trusted Third Party like a CA, and later 664 retrieved from it either by extortion or compromise 665 [Soghoian2011]. 667 o A cryptographic break-through, or the use of asymmetric keys with 668 insufficient length [Kleinjung2010]. 670 PFS ensures in such cases that the session keys cannot be determined 671 even by an attacker who obtains the long-term keys some time after 672 the conversation. It also protects against an attacker who is in 673 possession of the long-term keys, but remains passive during the 674 conversation. 676 PFS is generally achieved by using the Diffie-Hellman scheme to 677 derive session keys. The Diffie-Hellman scheme has both parties 678 maintain private secrets and send parameters over the network as 679 modular powers over certain cyclic groups. The properties of the so- 680 called Discrete Logarithm Problem (DLP) allow to derive the session 681 keys without an eavesdropper being able to do so. There is currently 682 no known attack against DLP if sufficiently large parameters are 683 chosen. A variant of the Diffie-Hellman scheme uses Elliptic Curves 684 instead of the originally proposed modular arithmetics. 686 Unfortunately, many TLS/DTLS cipher suites were defined that do not 687 feature PFS, e.g. TLS_RSA_WITH_AES_256_CBC_SHA256. We thus advocate 688 strict use of PFS-only ciphers. 690 7.4. Diffie-Hellman Exponent Reuse 692 For performance reasons, many TLS implementations reuse Diffie- 693 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 694 connections. Such reuse can result in major security issues: 696 o If exponents are reused for a long time (e.g., more than a few 697 hours), an attacker who gains access to the host can decrypt 698 previous connections. In other words, exponent reuse negates the 699 effects of forward secrecy. 701 o TLS implementations that reuse exponents should test the DH public 702 key they receive, in order to avoid some known attacks. These 703 tests are not standardized in TLS at the time of writing. See 704 [RFC6989] for recipient tests required of IKEv2 implementations 705 that reuse DH exponents. 707 7.5. Certificate Revocation 709 Unfortunately there is currently no effective, Internet-scale 710 mechanism to effect certificate revocation: 712 o Certificate Revocation Lists (CRLs) are non-scalable and therefore 713 rarely used. 715 o The On-Line Certification Status Protocol (OCSP) presents both 716 scaling and privacy issues when used for heavy traffic Web 717 servers. In addition, clients typically "soft-fail", meaning they 718 do not abort the TLS connection if the OCSP server does not 719 respond. 721 o OCSP stapling (Sec. 8 of [RFC6066]) resolves the operational 722 issues with OCSP, but is still ineffective in the presence of a 723 MITM attacker because the attacker can simply ignore the client's 724 request for a stapled OCSP response. 726 o OCSP stapling as defined in [RFC6066] does not extend to 727 intermediate certificates used in a certificate chain. [RFC6961] 728 addresses this shortcoming, but is a recent addition without much 729 deployment. 731 o Proprietary mechanisms that embed revocation lists in the Web 732 browser's configuration database cannot scale beyond a small 733 number of the most heavily used Web servers. 735 The current consensus appears to be that OCSP stapling, combined with 736 a "must staple" mechanism similar to HSTS, would finally resolve this 737 problem; in particular when used together with the extension defined 738 in [RFC6961]. But such a mechanism has not been standardized yet. 740 8. Acknowledgments 742 We would like to thank Uri Blumenthal, Viktor Dukhovni, Stephen 743 Farrell, Simon Josefsson, Watson Ladd, Orit Levin, Johannes Merkle, 744 Bodo Moeller, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom 745 Ritter, Rich Salz, Sean Turner, Aaron Zauner for their review and 746 improvements. Thanks to Brian Smith whose "browser cipher suites" 747 page is a great resource. Finally, thanks to all others who 748 commented on the TLS, UTA and other lists and are not mentioned here 749 by name. 751 9. References 753 9.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 760 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 761 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 762 for Transport Layer Security (TLS)", RFC 4492, May 2006. 764 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 765 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 767 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 768 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 769 August 2008. 771 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 772 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 773 August 2008. 775 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 776 "Transport Layer Security (TLS) Renegotiation Indication 777 Extension", RFC 5746, February 2010. 779 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 780 Verification of Domain-Based Application Service Identity 781 within Internet Public Key Infrastructure Using X.509 782 (PKIX) Certificates in the Context of Transport Layer 783 Security (TLS)", RFC 6125, March 2011. 785 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 786 (SSL) Version 2.0", RFC 6176, March 2011. 788 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 789 Security Version 1.2", RFC 6347, January 2012. 791 9.2. Informative References 793 [CAB-Baseline] 794 CA/Browser Forum, , "Baseline Requirements for the 795 Issuance and Management of Publicly-Trusted Certificates 796 Version 1.1.6", 2013, . 799 [DegabrieleP07] 800 Degabriele, J. and K. Paterson, "Attacking the IPsec 801 standards in encryption-only configurations", 2007, 802 . 804 [Heninger2012] 805 Heninger, N., Durumeric, Z., Wustrow, E., and J. 806 Halderman, "Mining Your Ps and Qs: Detection of Widespread 807 Weak Keys in Network Devices", Usenix Security Symposium 808 2012, 2012. 810 [I-D.dukhovni-smtp-opportunistic-tls] 811 Dukhovni, V. and W. Hardaker, "SMTP security via 812 opportunistic DANE TLS", draft-dukhovni-smtp- 813 opportunistic-tls-01 (work in progress), July 2013. 815 [I-D.farrelll-mpls-opportunistic-encrypt] 816 Farrel, A. and S. Farrell, "Opportunistic Encryption in 817 MPLS Networks", draft-farrelll-mpls-opportunistic- 818 encrypt-02 (work in progress), February 2014. 820 [I-D.ietf-dane-smtp] 821 Finch, T., "Secure SMTP using DNS-Based Authentication of 822 Named Entities (DANE) TLSA records.", draft-ietf-dane- 823 smtp-01 (work in progress), February 2013. 825 [I-D.ietf-dane-srv] 826 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 827 Based Authentication of Named Entities (DANE) TLSA Records 828 with SRV Records", draft-ietf-dane-srv-07 (work in 829 progress), July 2014. 831 [I-D.ietf-tls-prohibiting-rc4] 832 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 833 tls-prohibiting-rc4-00 (work in progress), July 2014. 835 [I-D.ietf-uta-tls-attacks] 836 Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 837 Current Attacks on TLS and DTLS", draft-ietf-uta-tls- 838 attacks-04 (work in progress), September 2014. 840 [Kleinjung2010] 841 Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", 842 CRYPTO 10, 2010, . 844 [PatersonRS11] 845 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size 846 does matter: attacks and proofs for the TLS record 847 protocol", 2011, 848 . 850 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 851 RFC 2246, January 1999. 853 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 854 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 856 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 857 Security", RFC 4347, April 2006. 859 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 860 4949, August 2007. 862 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 863 "Transport Layer Security (TLS) Session Resumption without 864 Server-Side State", RFC 5077, January 2008. 866 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 867 Encryption", RFC 5116, January 2008. 869 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 870 Extension Definitions", RFC 6066, January 2011. 872 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 873 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 874 August 2011. 876 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 877 Layer Security (TLS)", RFC 6460, January 2012. 879 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 880 Transport Security (HSTS)", RFC 6797, November 2012. 882 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 883 Multiple Certificate Status Request Extension", RFC 6961, 884 June 2013. 886 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 887 Tests for the Internet Key Exchange Protocol Version 2 888 (IKEv2)", RFC 6989, July 2013. 890 [Soghoian2011] 891 Soghoian, C. and S. Stamm, "Certified lies: Detecting and 892 defeating government interception attacks against SSL.", 893 Proc. 15th Int. Conf. Financial Cryptography and Data 894 Security , 2011. 896 [triple-handshake] 897 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 898 "Triple Handshakes Considered Harmful: Breaking and Fixing 899 Authentication over TLS", 2014, . 902 Appendix A. Change Log 904 Note to RFC Editor: please remove this section before publication. 906 A.1. draft-ietf-uta-tls-bcp-05 908 o Lots of comments by Sean Turner. 910 o Unauthenticated TLS, following a long thread on the list. 912 A.2. draft-ietf-uta-tls-bcp-04 914 o Some cleanup, and input from TLS WG discussion on applicability. 916 A.3. draft-ietf-uta-tls-bcp-03 918 o Disallow truncated HMAC. 920 o Applicability to DTLS. 922 o Some more text restructuring. 924 o Host name validation is sometimes irrelevant. 926 o HSTS: MUST implement, SHOULD deploy. 928 o Session identities are not protected, only tickets are. 930 o Clarified the target audience. 932 A.4. draft-ietf-uta-tls-bcp-02 934 o Rearranged some sections for clarity and re-styled the text so 935 that normative text is followed by rationale where possible. 937 o Removed the recommendation to use Brainpool curves. 939 o Triple Handshake mitigation. 941 o MUST NOT negotiate algorithms lower than 112 bits of security. 943 o MUST implement SNI, but use per local policy. 945 o Changed SHOULD NOT negotiate or fall back to SSLv3 to MUST NOT. 947 o Added hostname validation. 949 o Non-normative discussion of DH exponent reuse. 951 A.5. draft-ietf-tls-bcp-01 953 o Clarified that specific TLS-using protocols may have stricter 954 requirements. 956 o Changed TLS 1.0 from MAY to SHOULD NOT. 958 o Added discussion of "optional TLS" and HSTS. 960 o Recommended use of the Signature Algorithm and Renegotiation Info 961 extensions. 963 o Use of a strong cipher for a resumption ticket: changed SHOULD to 964 MUST. 966 o Added an informational discussion of certificate revocation, but 967 no recommendations. 969 A.6. draft-ietf-tls-bcp-00 971 o Initial WG version, with only updated references. 973 A.7. draft-sheffer-tls-bcp-02 975 o Reorganized the content to focus on recommendations. 977 o Moved description of attacks to a separate document (draft- 978 sheffer-uta-tls-attacks). 980 o Strengthened recommendations regarding session resumption. 982 A.8. draft-sheffer-tls-bcp-01 984 o Clarified our motivation in the introduction. 986 o Added a section justifying the need for PFS. 988 o Added recommendations for RSA and DH parameter lengths. Moved 989 from DHE to ECDHE, with a discussion on whether/when DHE is 990 appropriate. 992 o Recommendation to avoid fallback to SSLv3. 994 o Initial information about browser support - more still needed! 996 o More clarity on compression. 998 o Client can offer stronger cipher suites. 1000 o Discussion of the regular TLS mandatory cipher suite. 1002 A.9. draft-sheffer-tls-bcp-00 1004 o Initial version. 1006 Authors' Addresses 1008 Yaron Sheffer 1009 Porticor 1010 29 HaHarash St. 1011 Hod HaSharon 4501303 1012 Israel 1014 Email: yaronf.ietf@gmail.com 1016 Ralph Holz 1017 Technische Universitaet Muenchen 1018 Boltzmannstr. 3 1019 Garching 85748 1020 Germany 1022 Email: ralph.ietf@gmail.com 1024 Peter Saint-Andre 1025 &yet 1027 Email: peter@andyet.com 1028 URI: https://andyet.com/