idnits 2.17.1 draft-ietf-uta-tls-bcp-06.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 23, 2014) is 3466 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: April 26, 2015 TUM 6 P. Saint-Andre 7 &yet 8 October 23, 2014 10 Recommendations for Secure Use of TLS and DTLS 11 draft-ietf-uta-tls-bcp-06 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 April 26, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 Lower Versions . . . . . . . . . . . . . 7 68 4.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 9 71 4.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9 72 4.6. Server Name Indication . . . . . . . . . . . . . . . . . 10 73 5. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 10 74 5.1. General Guidelines . . . . . . . . . . . . . . . . . . . 10 75 5.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 11 76 5.3. Cipher Suite Negotiation Details . . . . . . . . . . . . 12 77 5.4. Public Key Length . . . . . . . . . . . . . . . . . . . . 12 78 5.5. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 13 79 5.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 16 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 90 9.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 92 A.1. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 21 93 A.2. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 21 94 A.3. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 21 95 A.4. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 21 96 A.5. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 21 97 A.6. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 22 98 A.7. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 22 99 A.8. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 22 100 A.9. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 22 101 A.10. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 Transport Layer Security (TLS) [RFC5246] and Datagram Transport 107 Security Layer (DTLS) [RFC6347] are widely used to protect data 108 exchanged over application protocols such as HTTP, SMTP, IMAP, POP, 109 SIP, and XMPP. Over the last few years, several serious attacks on 110 TLS have emerged, including attacks on its most commonly used cipher 111 suites and modes of operation. For instance, both the AES-CBC 112 [RFC3602] and RC4 [I-D.ietf-tls-prohibiting-rc4] encryption 113 algorithms, which together are the most widely deployed ciphers, have 114 been attacked in the context of TLS. A companion document 115 [I-D.ietf-uta-tls-attacks] provides detailed information about these 116 attacks. 118 Because of these attacks, those who implement and deploy TLS and DTLS 119 need updated guidance on how TLS can be used securely. This document 120 provides guidance for deployed services as well as for software 121 implementations, assuming the implementer expects his or her code to 122 be deployed in environments defined in the following section. In 123 fact, this document calls for the deployment of algorithms that are 124 widely implemented but not yet widely deployed. Concerning 125 deployment, this document targets a wide audience, namely all 126 deployers who wish to add authentication (be it one-way only or 127 mutual), confidentiality, and data integrity protection to their 128 communications. 130 The recommendations herein take into consideration the security of 131 various mechanisms, their technical maturity and interoperability, 132 and their prevalence in implementations at the time of writing. 133 Unless noted otherwise, these recommendations apply to both TLS and 134 DTLS. TLS 1.3, when it is standardized and deployed in the field, 135 should resolve the current vulnerabilities while providing 136 significantly better functionality. It will very likely obsolete 137 this document. 139 These are minimum recommendations for the use of TLS for the 140 specified audience. Individual specifications can have stricter 141 requirements related to one or more aspects of the protocol, based on 142 their particular circumstances (e.g., for use with a particular 143 application protocol). When that is the case, implementers are 144 advised to adhere to those stricter requirements. 146 Community knowledge about the strength of various algorithms and 147 feasible attacks can change quickly, and experience shows that a 148 security BCP is a point-in-time statement. Readers are advised to 149 seek out any errata or updates that apply to this document. 151 2. Intended Audience and Applicability Statement 153 The deployment recommendations of this document address the operators 154 of application layer services that are most commonly used on the 155 Internet, including, but not limited to: 157 o Operators of WWW servers that wish to protect HTTP with TLS. 159 o Operators of email servers who wish to protect the application- 160 layer protocols with TLS (e.g., IMAP, POP3 or SMTP). 162 o Operators of instant-messaging services who wish to protect their 163 application-layer protocols with TLS (e.g., XMPP or IRC). 165 2.1. Security Services 167 This document provides recommendations for an audience that wishes to 168 secure their communication with TLS to achieve the following: 170 o Confidentiality: all (payload) communication is encrypted with the 171 goal that no party should be able to decrypt it except the 172 intended receiver. 174 o Data integrity: any changes made to the communication in transit 175 are detectable by the receiver. 177 o Authentication: an end-point of the TLS communication is 178 authenticated as the intended entity to communicate with. TLS 179 enables authentication of one or both end-points in the 180 communication. Some TLS usage scenarios do not require 181 authentication. They are not in the scope of this document. We 182 discuss them under Section 2.2. 184 If deployers deviate from the recommendations given in this document, 185 they MUST verify that they do not need one of the foregoing security 186 services. 188 This document applies only to environments where confidentiality is 189 required. It recommends algorithms and configuration options that 190 enforce secrecy of the data-in-transit. 192 This document also assumes that data integrity protection is always 193 one of the goals of a deployment. In cases where integrity is not 194 required, it does not make sense to employ TLS in the first place. 195 There are attacks against confidentiality-only protection that 196 utilize the lack of integrity to also break confidentiality (see for 197 instance [DegabrieleP07] in the context of IPsec). 199 The intended audience covers those services that are most commonly 200 used on the Internet. Typically, all communication between TLS 201 clients and TLS servers requires all three of the above security 202 services. This is particularly true where TLS clients are user 203 agents like Web browsers or email software. 205 This document does not address the rarer deployment scenarios where 206 one of the above three properties is not desired, such as the use 207 case described under Section 2.2 below. Another example of an 208 audience not needing confidentiality is the following: a monitored 209 network where the authorities in charge of the respective traffic 210 domain require full access to unencrypted (plaintext) traffic, and 211 where users collaborate and send their traffic in the clear. 213 2.2. Unauthenticated TLS 215 Several important applications use TLS to protect data between a TLS 216 client and a TLS server, but do so without the TLS client verifying 217 the server's certificate. The reader is referred to 218 [I-D.ietf-dane-smtp-with-dane] for an example and an explanation of 219 why this less secure practice will likely remain common in the 220 context of SMTP (especially for MTA-to-MTA communications). The 221 practice is also encountered in similar contexts such as server-to- 222 server XMPP traffic. 224 In some of these scenarios the use of TLS is optional, i.e. the 225 client decides dynamically ("opportunistically") whether to use TLS 226 with a particular server or to connect in the clear. (Opportunistic 227 encryption is described at length in Section 2 of 228 [I-D.farrelll-mpls-opportunistic-encrypt].) In other scenarios, the 229 use of TLS is required but certificates are not always checked (e.g., 230 this is often the case on the XMPP network, where multi-tenant 231 hosting environments make it difficult for operators to obtain proper 232 certificates for all of the domains they service). 234 It can be argued that the recommendations provided in this document 235 ought to apply equally to unauthenticated TLS as well as 236 authenticated TLS. That would keep TLS implementations and 237 deployments in sync, which is a desirable property given that servers 238 can be used simultaneously for unauthenticated TLS and for 239 authenticated TLS (indeed, often a server will not know whether a 240 client might attempt authenticated or unauthenticated TLS). On the 241 other hand, it has been argued that some of the recommendations in 242 this document might be too strict for unauthenticated scenarios and 243 that any security is better than no security at all (i.e., sending 244 traffic in the clear), even if it means deploying outdated protocol 245 versions and ciphers in unauthenticated scenarios. The sense of the 246 UTA Working Group was to complete work on this document about 247 authenticated TLS and to initiate work on a separate document about 248 unauthenticated TLS. 250 In summary: this document does not apply to unauthenticated TLS use 251 cases. 253 3. Terminology 255 A number of security-related terms in this document are used in the 256 sense defined in [RFC4949]. 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in [RFC2119]. 262 4. General Recommendations 264 This section provides general recommendations on the secure use of 265 TLS. Recommendations related to cipher suites are discussed in the 266 following section. 268 4.1. Protocol Versions 270 4.1.1. SSL/TLS Protocol Versions 272 It is important both to stop using old, less secure versions of SSL/ 273 TLS and to start using modern, more secure versions; therefore, the 274 following are the recommendations concerning TLS/SSL protocol 275 versions: 277 o Implementations MUST NOT negotiate SSL version 2. 279 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 281 o Implementations MUST NOT negotiate SSL version 3. 283 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 284 plugged some significant security holes, but did not support 285 strong cipher suites. SSLv3 does not support TLS extensions, some 286 of which (e.g. renegotiation_info) are security-critical. In 287 addition, with the emergence of the POODLE attack [POODLE], SSLv3 288 is now widely recognized as fundamentally insecure. 290 o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]. 292 Rationale: TLS 1.0 (published in 1999) does not support many 293 modern, strong cipher suites. 295 o Implementations MAY negotiate TLS version 1.1 [RFC4346]. 297 Rationale: TLS 1.1 (published in 2006) is a security improvement 298 over TLS 1.0, but still does not support certain stronger cipher 299 suites. 301 o Implementations MUST support, and prefer to negotiate, TLS version 302 1.2 [RFC5246]. 304 Rationale: Several stronger cipher suites are available only with 305 TLS 1.2 (published in 2008). In fact, the cipher suites 306 recommended by this document (Section 5.2 below) are only 307 available in TLS 1.2. 309 This BCP applies to TLS 1.2. It is not safe for readers to assume 310 that the recommendations in this BCP apply to any future version of 311 TLS. 313 4.1.2. DTLS Protocol Versions 315 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 316 1.1 was published. The following are the recommendations with 317 respect to DTLS: 319 o Implementations MAY negotiate DTLS version 1.0 [RFC4347]. 321 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 323 o Implementations MUST support, and prefer to negotiate, DTLS 324 version 1.2 [RFC6347]. 326 Version 1.2 of DTLS correlates to Version 1.2 of TLS 1.2 (see 327 above). (There is no Version 1.1 of DTLS.) 329 Note: DTLS and TLS are nearly identical. The most notable exception 330 is that RC4, which is a stream-based bulk encryption algorithm, 331 cannot be supported by DTLS. 333 4.1.3. Fallback to Lower Versions 335 Clients that "fallback" to lower versions of the protocol after the 336 server rejects higher versions of the protocol MUST NOT fallback to 337 SSLv3. 339 Rationale: Some client implementations revert to lower versions of 340 TLS or even to SSLv3 if the server rejected higher versions of the 341 protocol. This fallback can be forced by a man in the middle (MITM) 342 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 343 1.2, the version recommended by this document. While TLS 1.0-only 344 servers are still quite common, IP scans show that SSLv3-only servers 345 amount to only about 3% of the current Web server population. 347 4.2. Strict TLS 349 To prevent SSL Stripping: 351 o In cases where an application protocol allows implementations or 352 deployments a choice between strict TLS configuration and dynamic 353 upgrade from unencrypted to TLS-protected traffic (such as 354 STARTTLS), clients and servers SHOULD prefer strict TLS 355 configuration. 357 o In many application protocols, clients can be configured to use 358 TLS even if the server has not advertised that TLS is mandatory or 359 even supported (e.g., this is often the case in messaging 360 protocols such as IMAP and XMPP). Application clients SHOULD use 361 TLS by default, and disable this default only through explicit 362 configuration by the user. 364 o HTTP client and server implementations MUST support the HTTP 365 Strict Transport Security (HSTS) header [RFC6797], in order to 366 allow Web servers to advertise that they are willing to accept 367 TLS-only clients. 369 o When applicable, Web servers SHOULD use HSTS to indicate that they 370 are willing to accept TLS-only clients. 372 Rationale: Combining unprotected and TLS-protected communication 373 opens the way to SSL Stripping and similar attacks, since an initial 374 part of the communication is not integrity protected and therefore 375 can be manipulated by an attacker whose goal is to keep the 376 communication in the clear. 378 4.3. Compression 380 Implementations and deployments SHOULD disable TLS-level compression 381 ([RFC5246], Sec. 6.2.2). 383 Rationale: TLS compression has been subject to security attacks, such 384 as the CRIME attack. 386 Implementers should note that compression at higher protocol levels 387 can allow an active attacker to extract cleartext information from 388 the connection. The BREACH attack is one such case. These issues 389 can only be mitigated outside of TLS and are thus out of scope of the 390 current document. See Sec. 2.5 of [I-D.ietf-uta-tls-attacks] for 391 further details. 393 4.4. TLS Session Resumption 395 If TLS session resumption is used, care ought to be taken to do so 396 safely. In particular, when using session tickets [RFC5077], the 397 resumption information MUST be authenticated and encrypted to prevent 398 modification or eavesdropping by an attacker. Further 399 recommendations apply to session tickets: 401 o A strong cipher suite MUST be used when encrypting the ticket (as 402 least as strong as the main TLS cipher suite). 404 o Ticket keys MUST be changed regularly, e.g. once every week, so as 405 not to negate the benefits of forward secrecy (see Section 7.3 for 406 details on forward secrecy). 408 o Session ticket validity SHOULD be limited to a reasonable duration 409 (e.g. 1 day), for similar reasons. 411 Rationale: session resumption is another kind of TLS handshake, and 412 therefore must be as secure as the initial handshake. This document 413 (Section 5) recommends the use of cipher suites that provide forward 414 secrecy, i.e. that prevent an attacker who gains momentary access to 415 the TLS endpoint (either client or server) and its secrets from 416 reading either past or future communication. The tickets must be 417 managed so as not to negate this security property. 419 4.5. TLS Renegotiation 421 Where handshake renegotiation is implemented, both clients and 422 servers MUST implement the renegotiation_info extension, as defined 423 in [RFC5746]. 425 To counter the Triple Handshake attack, we adopt the recommendation 426 from [triple-handshake]: TLS clients SHOULD ensure that all 427 certificates received over a connection are valid for the current 428 server endpoint, and abort the handshake if they are not. In some 429 usages, it may be simplest to refuse any change of certificates 430 during renegotiation. 432 4.6. Server Name Indication 434 TLS implementations MUST support the Server Name Indication (SNI) 435 extension for those higher level protocols which would benefit from 436 it, including HTTPS. However, unlike implementation, the use of SNI 437 in particular circumstances is a matter of local policy. 439 Rationale: SNI supports deployment of multiple TLS-protected virtual 440 servers on a single address, and therefore enables fine-grained 441 security for these virtual servers, by allowing each one to have its 442 own certificate. 444 5. Recommendations: Cipher Suites 446 TLS and its implementations provide considerable flexibility in the 447 selection of cipher suites. Unfortunately, some available cipher 448 suites are insecure, some do not provide the targeted security 449 services, and some no longer provide enough security. Incorrectly 450 configuring a server leads to no or reduced security. This section 451 includes recommendations on the selection and negotiation of cipher 452 suites. 454 5.1. General Guidelines 456 Cryptographic algorithms weaken over time as cryptanalysis improves. 457 In other words, as time progresses, algorithms that were once 458 considered strong but are now weak, need to be phased out over time 459 and replaced with more secure cipher suites to ensure that desired 460 security properties still hold. SSL/TLS has been in existence for 461 almost 20 years at this point and this section provides some much 462 needed recommendations concerning cipher suite selection: 464 o Implementations MUST NOT negotiate the cipher suites with NULL 465 encryption. 467 Rationale: The NULL cipher suites do not encrypt traffic and so 468 provide no confidentiality services. Any entity in the network 469 with access to the connection can view the plaintext of contents 470 being exchanged by the client and server. 472 o Implementations MUST NOT negotiate RC4 cipher suites. 474 Rationale: The RC4 stream cipher has a variety of cryptographic 475 weaknesses, as documented in [I-D.ietf-tls-prohibiting-rc4]. We 476 note that this guideline does not apply to DTLS, which 477 specifically forbids the use of RC4. 479 o Implementations MUST NOT negotiate cipher suites offering only so- 480 called "export-level" encryption (including algorithms with 40 481 bits or 56 bits of security). 483 Rationale: These cipher suites are deliberately "dumbed down" and 484 are very easy to break. 486 o Implementations MUST NOT negotiate cipher suites offering less 487 than 112 bits of security, including the so-called "export-level" 488 encryption (which provide 40 or 56 bits of security). 490 Rationale: Based on [RFC3766], at least 112 bits of security is 491 needed. 40-bit and 56-bit security are considered insecure today. 492 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. 494 o Implementations SHOULD NOT negotiate cipher suites that use 495 algorithms offering less than 128 bits of security. 497 Rationale: Cipher suites that offer between 112-bits and 128-bits 498 of security are not considered weak at this time, however it is 499 expected that their useful lifespan is short enough to justify 500 supporting stronger cipher suites at this time. 128-bit ciphers 501 are expected to remain secure for at least several years, and 502 256-bit ciphers "until the next fundamental technology 503 breakthrough". Note that some legacy cipher suites (e.g. 168-bit 504 3DES) have an effective key length which is smaller than their 505 nominal key length (112 bits in the case of 3DES). Such cipher 506 suites should be evaluated according to their effective key 507 length. 509 o Implementations MUST support, and SHOULD prefer to negotiate, 510 cipher suites offering forward secrecy, such as those in the 511 Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie- 512 Hellman ("DHE" and "ECDHE") families. 514 Rationale: Forward secrecy (sometimes called "perfect forward 515 secrecy") prevents the recovery of information that was encrypted 516 with older session keys, thus limiting the amount of time during 517 which attacks can be successful. 519 5.2. Recommended Cipher Suites 521 Given the foregoing considerations, implementation and deployment of 522 the following cipher suites is RECOMMENDED: 524 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 526 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 527 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 529 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 531 These cipher suites are supported only in TLS 1.2 since they are 532 authenticated encryption (AEAD) algorithms [RFC5116]. 534 Typically, in order to prefer these suites, the order of suites needs 535 to be explicitly configured in server software. 537 [RFC4492] allows clients and servers to negotiate ECDH parameters 538 (curves). Both clients and servers SHOULD include the "Supported 539 Elliptic Curves" extension [RFC4492]. For interoperability, clients 540 and servers SHOULD support the NIST P-256 (secp256r1) curve 541 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 542 extension with a single element, "uncompressed". 544 5.3. Cipher Suite Negotiation Details 546 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 547 first proposal to any server, unless they have prior knowledge that 548 the server cannot respond to a TLS 1.2 client_hello message. 550 Servers SHOULD prefer this cipher suite whenever it is proposed, even 551 if it is not the first proposal. 553 Clients are of course free to offer stronger cipher suites, e.g. 554 using AES-256; when they do, the server SHOULD prefer the stronger 555 cipher suite unless there are compelling reasons (e.g., seriously 556 degraded performance) to choose otherwise. 558 Note that other profiles of TLS 1.2 exist that use different cipher 559 suites. For example, [RFC6460] defines a profile that uses the 560 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 561 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 563 This document is not an application profile standard, in the sense of 564 Sec. 9 of [RFC5246]. As a result, clients and servers are still 565 REQUIRED to support the mandatory TLS cipher suite, 566 TLS_RSA_WITH_AES_128_CBC_SHA. 568 5.4. Public Key Length 570 When using the cipher suites recommended in this document, two public 571 keys are normally used in the TLS handshake: one for the Diffie- 572 Hellman key agreement and one for server authentication. Where a 573 client certificate is used, a third one is added. 575 With a key exchange based on modular Diffie-Hellman ("DHE" cipher 576 suites), DH key lengths of at least 2048 bits are RECOMMENDED. 578 Rationale: because Diffie-Hellman keys of 1024 bits are estimated to 579 be roughly equivalent to 80-bit symmetric keys, it is better to use 580 longer keys for the "DHE" family of cipher suites. Key lengths of at 581 least 2048 bits are estimated to be roughly equivalent to 112-bit 582 symmetric keys and might be sufficient for at least the next 583 10 years. See Section 5.5 for additional information on the use of 584 modular Diffie-Hellman in TLS. 586 Servers SHOULD authenticate using 2048-bit certificates. In 587 addition, the use of SHA-256 fingerprints is RECOMMENDED (see 588 [CAB-Baseline] for more details). Clients SHOULD indicate to servers 589 that they request SHA-256, by using the "Signature Algorithms" 590 extension defined in TLS 1.2. 592 5.5. Modular vs. Elliptic Curve DH Cipher Suites 594 Not all TLS implementations support both modular and EC Diffie- 595 Hellman groups, as required by Section 5.2. Some implementations are 596 severely limited in the length of DH values. When such 597 implementations need to be accommodated, we recommend using (in 598 priority order): 600 1. Elliptic Curve DHE with negotiated parameters [RFC5289] 602 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 603 Diffie-Hellman parameters 605 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters. 607 Rationale: Elliptic Curve Cryptography is not universally deployed 608 for several reasons, including its complexity compared to modular 609 arithmetic and longstanding IPR concerns. On the other hand, there 610 are two related issues hindering effective use of modular Diffie- 611 Hellman cipher suites in TLS: 613 o There are no protocol mechanisms to negotiate the DH groups or 614 parameter lengths supported by client and server. 616 o There are widely deployed client implementations that reject 617 received DH parameters if they are longer than 1024 bits. 619 We note that with DHE and ECDHE cipher suites, the TLS master key 620 only depends on the Diffie-Hellman parameters and not on the strength 621 of the RSA certificate; moreover, 1024 bit modular DH parameters are 622 generally considered insufficient at this time. 624 With modular ephemeral DH, deployers SHOULD carefully evaluate 625 interoperability vs. security considerations when configuring their 626 TLS endpoints. 628 5.6. Truncated HMAC 630 Implementations MUST NOT use the Truncated HMAC extension, defined in 631 Sec. 7 of [RFC6066]. 633 Rationale: the extension does not apply to the AEAD cipher suites 634 recommended above. However it does apply to most other TLS cipher 635 suites. Its use has been shown to be insecure in [PatersonRS11]. 637 6. IANA Considerations 639 This document requests no actions of IANA. [Note to RFC Editor: 640 please remove this whole section before publication.] 642 7. Security Considerations 644 This entire document discusses the security practices directly 645 affecting applications using the TLS protocol. This section contains 646 broader security considerations related to technologies used in 647 conjunction with or by TLS. 649 7.1. Host Name Validation 651 Application authors should take note that TLS implementations 652 frequently do not validate host names and must therefore determine if 653 the TLS implementation they are using does and, if not, write their 654 own validation code or consider changing the TLS implementation. 656 It is noted that the requirements regarding host name validation (and 657 in general, binding between the TLS layer and the protocol that runs 658 above it) vary between different protocols. For HTTPS, these 659 requirements are defined by Sec. 3 of [RFC2818]. 661 Readers are referred to [RFC6125] for further details regarding 662 generic host name validation in the TLS context. In addition, the 663 RFC contains a long list of example protocols, some of which 664 implement a policy very different from HTTPS. 666 If the host name is discovered indirectly and in an insecure manner 667 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 668 NOT be used as a reference identifier [RFC6125] even when it matches 669 the presented certificate. This proviso does not apply if the host 670 name is discovered securely (for further discussion, see for example 671 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]). 673 7.2. AES-GCM 675 Section 5.2 above recommends the use of the AES-GCM authenticated 676 encryption algorithm. Please refer to [RFC5246], Sec. 11 for general 677 security considerations when using TLS 1.2, and to [RFC5288], Sec. 6 678 for security considerations that apply specifically to AES-GCM when 679 used with TLS. 681 7.3. Forward Secrecy 683 Forward secrecy (also often called Perfect Forward Secrecy or "PFS" 684 and defined in [RFC4949]) is a defense against an attacker who 685 records encrypted conversations where the session keys are only 686 encrypted with the communicating parties' long-term keys. Should the 687 attacker be able to obtain these long-term keys at some point later 688 in time, he will be able to decrypt the session keys and thus the 689 entire conversation. In the context of TLS and DTLS, such compromise 690 of long-term keys is not entirely implausible. It can happen, for 691 example, due to: 693 o A client or server being attacked by some other attack vector, and 694 the private key retrieved. 696 o A long-term key retrieved from a device that has been sold or 697 otherwise decommissioned without prior wiping. 699 o A long-term key used on a device as a default key [Heninger2012]. 701 o A key generated by a Trusted Third Party like a CA, and later 702 retrieved from it either by extortion or compromise 703 [Soghoian2011]. 705 o A cryptographic break-through, or the use of asymmetric keys with 706 insufficient length [Kleinjung2010]. 708 PFS ensures in such cases that the session keys cannot be determined 709 even by an attacker who obtains the long-term keys some time after 710 the conversation. It also protects against an attacker who is in 711 possession of the long-term keys, but remains passive during the 712 conversation. 714 PFS is generally achieved by using the Diffie-Hellman scheme to 715 derive session keys. The Diffie-Hellman scheme has both parties 716 maintain private secrets and send parameters over the network as 717 modular powers over certain cyclic groups. The properties of the so- 718 called Discrete Logarithm Problem (DLP) allow to derive the session 719 keys without an eavesdropper being able to do so. There is currently 720 no known attack against DLP if sufficiently large parameters are 721 chosen. A variant of the Diffie-Hellman scheme uses Elliptic Curves 722 instead of the originally proposed modular arithmetics. 724 Unfortunately, many TLS/DTLS cipher suites were defined that do not 725 feature PFS, e.g. TLS_RSA_WITH_AES_256_CBC_SHA256. We thus advocate 726 strict use of PFS-only ciphers. 728 7.4. Diffie-Hellman Exponent Reuse 730 For performance reasons, many TLS implementations reuse Diffie- 731 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 732 connections. Such reuse can result in major security issues: 734 o If exponents are reused for a long time (e.g., more than a few 735 hours), an attacker who gains access to the host can decrypt 736 previous connections. In other words, exponent reuse negates the 737 effects of forward secrecy. 739 o TLS implementations that reuse exponents should test the DH public 740 key they receive, in order to avoid some known attacks. These 741 tests are not standardized in TLS at the time of writing. See 742 [RFC6989] for recipient tests required of IKEv2 implementations 743 that reuse DH exponents. 745 7.5. Certificate Revocation 747 Unfortunately, no mechanism exists at this time that we can recommend 748 as a complete and efficient solution for the problem of checking the 749 revocation status of common public key certificates (a.k.a. PKIX 750 certificates, [RFC5280]). The current state of the art is as 751 follows: 753 o Certificate Revocation Lists (CRLs) are not scalable and therefore 754 rarely used. 756 o The On-Line Certification Status Protocol (OCSP) presents both 757 scaling and privacy issues when used for heavy traffic Web 758 servers. In addition, clients typically "soft-fail", meaning they 759 do not abort the TLS connection if the OCSP server does not 760 respond. 762 o OCSP stapling (Section 8 of [RFC6066]) resolves the operational 763 issues with OCSP, but is still ineffective in the presence of a 764 MITM attacker because the attacker can simply ignore the client's 765 request for a stapled OCSP response. 767 o OCSP stapling as defined in [RFC6066] does not extend to 768 intermediate certificates used in a certificate chain. [RFC6961] 769 addresses this shortcoming, but is a recent addition without much 770 deployment. 772 o Proprietary mechanisms that embed revocation lists in the Web 773 browser's configuration database cannot scale beyond a small 774 number of the most heavily used Web servers. 776 With regard to PKIX certificates, servers SHOULD support OCSP and 777 OCSP stapling, including the OCSP stapling extension defined in 778 [RFC6961], as a best practice given the current state of the art and 779 as a foundation for a possible future solution. 781 The foregoing considerations do not apply to DANE certificates 782 [RFC6698], since they do not require a revocation mechanism. 784 8. Acknowledgments 786 We would like to thank Uri Blumenthal, Viktor Dukhovni, Stephen 787 Farrell, Simon Josefsson, Watson Ladd, Orit Levin, Johannes Merkle, 788 Bodo Moeller, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom 789 Ritter, Rich Salz, Sean Turner, and Aaron Zauner for their feedback 790 and suggested improvements. Thanks to Brian Smith whose "browser 791 cipher suites" page is a great resource. Finally, thanks to all 792 others who commented on the TLS, UTA and other lists and are not 793 mentioned here by name. 795 9. References 797 9.1. Normative References 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 804 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 805 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 806 RFC 3766, April 2004. 808 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 809 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 810 for Transport Layer Security (TLS)", RFC 4492, May 2006. 812 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 813 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 815 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 816 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 817 August 2008. 819 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 820 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 821 August 2008. 823 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 824 "Transport Layer Security (TLS) Renegotiation Indication 825 Extension", RFC 5746, February 2010. 827 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 828 Verification of Domain-Based Application Service Identity 829 within Internet Public Key Infrastructure Using X.509 830 (PKIX) Certificates in the Context of Transport Layer 831 Security (TLS)", RFC 6125, March 2011. 833 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 834 (SSL) Version 2.0", RFC 6176, March 2011. 836 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 837 Security Version 1.2", RFC 6347, January 2012. 839 9.2. Informative References 841 [CAB-Baseline] 842 CA/Browser Forum, , "Baseline Requirements for the 843 Issuance and Management of Publicly-Trusted Certificates 844 Version 1.1.6", 2013, . 847 [DegabrieleP07] 848 Degabriele, J. and K. Paterson, "Attacking the IPsec 849 standards in encryption-only configurations", 2007, 850 . 852 [Heninger2012] 853 Heninger, N., Durumeric, Z., Wustrow, E., and J. 854 Halderman, "Mining Your Ps and Qs: Detection of Widespread 855 Weak Keys in Network Devices", Usenix Security Symposium 856 2012, 2012. 858 [I-D.farrelll-mpls-opportunistic-encrypt] 859 Farrel, A. and S. Farrell, "Opportunistic Encryption in 860 MPLS Networks", draft-farrelll-mpls-opportunistic- 861 encrypt-02 (work in progress), February 2014. 863 [I-D.ietf-dane-smtp-with-dane] 864 Dukhovni, V. and W. Hardaker, "SMTP security via 865 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 866 (work in progress), May 2014. 868 [I-D.ietf-dane-srv] 869 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 870 Based Authentication of Named Entities (DANE) TLSA Records 871 with SRV Records", draft-ietf-dane-srv-06 (work in 872 progress), June 2014. 874 [I-D.ietf-tls-prohibiting-rc4] 875 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 876 tls-prohibiting-rc4-01 (work in progress), October 2014. 878 [I-D.ietf-uta-tls-attacks] 879 Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 880 Current Attacks on TLS and DTLS", draft-ietf-uta-tls- 881 attacks-04 (work in progress), September 2014. 883 [Kleinjung2010] 884 Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", 885 CRYPTO 10, 2010, . 887 [POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE 888 Bites: Exploiting the SSL 3.0 Fallback", 2014, . 891 [PatersonRS11] 892 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size 893 does matter: attacks and proofs for the TLS record 894 protocol", 2011, 895 . 897 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 898 RFC 2246, January 1999. 900 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 901 Algorithm and Its Use with IPsec", RFC 3602, September 902 2003. 904 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 905 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 907 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 908 Security", RFC 4347, April 2006. 910 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 911 4949, August 2007. 913 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 914 "Transport Layer Security (TLS) Session Resumption without 915 Server-Side State", RFC 5077, January 2008. 917 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 918 Encryption", RFC 5116, January 2008. 920 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 921 Housley, R., and W. Polk, "Internet X.509 Public Key 922 Infrastructure Certificate and Certificate Revocation List 923 (CRL) Profile", RFC 5280, May 2008. 925 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 926 Extension Definitions", RFC 6066, January 2011. 928 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 929 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 930 August 2011. 932 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 933 Layer Security (TLS)", RFC 6460, January 2012. 935 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 936 of Named Entities (DANE) Transport Layer Security (TLS) 937 Protocol: TLSA", RFC 6698, August 2012. 939 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 940 Transport Security (HSTS)", RFC 6797, November 2012. 942 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 943 Multiple Certificate Status Request Extension", RFC 6961, 944 June 2013. 946 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 947 Tests for the Internet Key Exchange Protocol Version 2 948 (IKEv2)", RFC 6989, July 2013. 950 [Soghoian2011] 951 Soghoian, C. and S. Stamm, "Certified lies: Detecting and 952 defeating government interception attacks against SSL.", 953 Proc. 15th Int. Conf. Financial Cryptography and Data 954 Security , 2011. 956 [triple-handshake] 957 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 958 "Triple Handshakes Considered Harmful: Breaking and Fixing 959 Authentication over TLS", 2014, . 962 Appendix A. Change Log 964 Note to RFC Editor: please remove this section before publication. 966 A.1. draft-ietf-uta-tls-bcp-06 968 o Undo unauthenticated TLS, following another long thread on the 969 list. 971 A.2. draft-ietf-uta-tls-bcp-05 973 o Lots of comments by Sean Turner. 975 o Unauthenticated TLS, following a long thread on the list. 977 A.3. draft-ietf-uta-tls-bcp-04 979 o Some cleanup, and input from TLS WG discussion on applicability. 981 A.4. draft-ietf-uta-tls-bcp-03 983 o Disallow truncated HMAC. 985 o Applicability to DTLS. 987 o Some more text restructuring. 989 o Host name validation is sometimes irrelevant. 991 o HSTS: MUST implement, SHOULD deploy. 993 o Session identities are not protected, only tickets are. 995 o Clarified the target audience. 997 A.5. draft-ietf-uta-tls-bcp-02 999 o Rearranged some sections for clarity and re-styled the text so 1000 that normative text is followed by rationale where possible. 1002 o Removed the recommendation to use Brainpool curves. 1004 o Triple Handshake mitigation. 1006 o MUST NOT negotiate algorithms lower than 112 bits of security. 1008 o MUST implement SNI, but use per local policy. 1010 o Changed SHOULD NOT negotiate or fall back to SSLv3 to MUST NOT. 1012 o Added hostname validation. 1014 o Non-normative discussion of DH exponent reuse. 1016 A.6. draft-ietf-tls-bcp-01 1018 o Clarified that specific TLS-using protocols may have stricter 1019 requirements. 1021 o Changed TLS 1.0 from MAY to SHOULD NOT. 1023 o Added discussion of "optional TLS" and HSTS. 1025 o Recommended use of the Signature Algorithm and Renegotiation Info 1026 extensions. 1028 o Use of a strong cipher for a resumption ticket: changed SHOULD to 1029 MUST. 1031 o Added an informational discussion of certificate revocation, but 1032 no recommendations. 1034 A.7. draft-ietf-tls-bcp-00 1036 o Initial WG version, with only updated references. 1038 A.8. draft-sheffer-tls-bcp-02 1040 o Reorganized the content to focus on recommendations. 1042 o Moved description of attacks to a separate document (draft- 1043 sheffer-uta-tls-attacks). 1045 o Strengthened recommendations regarding session resumption. 1047 A.9. draft-sheffer-tls-bcp-01 1049 o Clarified our motivation in the introduction. 1051 o Added a section justifying the need for PFS. 1053 o Added recommendations for RSA and DH parameter lengths. Moved 1054 from DHE to ECDHE, with a discussion on whether/when DHE is 1055 appropriate. 1057 o Recommendation to avoid fallback to SSLv3. 1059 o Initial information about browser support - more still needed! 1061 o More clarity on compression. 1063 o Client can offer stronger cipher suites. 1065 o Discussion of the regular TLS mandatory cipher suite. 1067 A.10. draft-sheffer-tls-bcp-00 1069 o Initial version. 1071 Authors' Addresses 1073 Yaron Sheffer 1074 Porticor 1075 29 HaHarash St. 1076 Hod HaSharon 4501303 1077 Israel 1079 Email: yaronf.ietf@gmail.com 1081 Ralph Holz 1082 Technische Universitaet Muenchen 1083 Boltzmannstr. 3 1084 Garching 85748 1085 Germany 1087 Email: ralph.ietf@gmail.com 1089 Peter Saint-Andre 1090 &yet 1092 Email: peter@andyet.com 1093 URI: https://andyet.com/