idnits 2.17.1 draft-ietf-uta-tls-bcp-08.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (December 7, 2014) is 3427 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-tls-downgrade-scsv-02 == 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 (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: Best Current Practice R. Holz 5 Expires: June 10, 2015 TUM 6 P. Saint-Andre 7 &yet 8 December 7, 2014 10 Recommendations for Secure Use of TLS and DTLS 11 draft-ietf-uta-tls-bcp-08 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 June 10, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. General Recommendations . . . . . . . . . . . . . . . . . . . 4 61 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 4 63 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 5 64 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 6 65 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 7 68 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 7 69 3.6. Server Name Indication . . . . . . . . . . . . . . . . . 8 70 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 8 71 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 8 72 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 9 73 4.2.1. Implementation Details . . . . . . . . . . . . . . . 10 74 4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 11 75 4.4. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 11 76 4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 12 77 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 13 78 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Unauthenticated TLS and Opportunistic Security . . . . . 14 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 15 83 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 16 85 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 17 86 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 17 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 9.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 92 A.1. draft-ietf-uta-tls-bcp-08 . . . . . . . . . . . . . . . . 23 93 A.2. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 23 94 A.3. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 23 95 A.4. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 23 96 A.5. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 23 97 A.6. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 23 98 A.7. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 24 99 A.8. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 24 100 A.9. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 24 101 A.10. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 25 102 A.11. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 25 103 A.12. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 25 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 Transport Layer Security (TLS) [RFC5246] and Datagram Transport 109 Security Layer (DTLS) [RFC6347] are widely used to protect data 110 exchanged over application protocols such as HTTP, SMTP, IMAP, POP, 111 SIP, and XMPP. Over the last few years, several serious attacks on 112 TLS have emerged, including attacks on its most commonly used cipher 113 suites and modes of operation. For instance, both the AES-CBC 114 [RFC3602] and RC4 [I-D.ietf-tls-prohibiting-rc4] encryption 115 algorithms, which together are the most widely deployed ciphers, have 116 been attacked in the context of TLS. A companion document 117 [I-D.ietf-uta-tls-attacks] provides detailed information about these 118 attacks. 120 Because of these attacks, those who implement and deploy TLS and DTLS 121 need updated guidance on how TLS can be used securely. This document 122 provides guidance for deployed services as well as for software 123 implementations, assuming the implementer expects his or her code to 124 be deployed in environments defined in the following section. In 125 fact, this document calls for the deployment of algorithms that are 126 widely implemented but not yet widely deployed. Concerning 127 deployment, this document targets a wide audience, namely all 128 deployers who wish to add authentication (be it one-way only or 129 mutual), confidentiality, and data integrity protection to their 130 communications. 132 The recommendations herein take into consideration the security of 133 various mechanisms, their technical maturity and interoperability, 134 and their prevalence in implementations at the time of writing. 135 Unless it is explicitly called out that a recommendation applies to 136 TLS alone or to DTLS alone, each recommendation applies to both TLS 137 and DTLS. 139 It is expected that the TLS 1.3 specification will resolve many of 140 the vulnerabilities listed in this document. A system that deploys 141 TLS 1.3 will have fewer vulnerabilities than TLS 1.2 or below. This 142 document is likely to be updated after TLS 1.3 gets noticeable 143 deployment. 145 These are minimum recommendations for the use of TLS in the vast 146 majority of implementation and deployment scenarios, with the 147 exception of unauthenticated TLS (see Section 5). Other 148 specifications that reference this document can have stricter 149 requirements related to one or more aspects of the protocol, based on 150 their particular circumstances (e.g., for use with a particular 151 application protocol); when that is the case, implementers are 152 advised to adhere to those stricter requirements. Furthermore, this 153 document provides a floor, not a ceiling, so stronger options are 154 always allowed (e.g., depending on differing evaluations of the 155 importance of cryptographic strength vs. computational load). 157 Community knowledge about the strength of various algorithms and 158 feasible attacks can change quickly, and experience shows that a 159 security BCP is a point-in-time statement. Readers are advised to 160 seek out any errata or updates that apply to this document. 162 2. Terminology 164 A number of security-related terms in this document are used in the 165 sense defined in [RFC4949]. 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 3. General Recommendations 173 This section provides general recommendations on the secure use of 174 TLS. Recommendations related to cipher suites are discussed in the 175 following section. 177 3.1. Protocol Versions 179 3.1.1. SSL/TLS Protocol Versions 181 It is important both to stop using old, less secure versions of SSL/ 182 TLS and to start using modern, more secure versions; therefore, the 183 following are the recommendations concerning TLS/SSL protocol 184 versions: 186 o Implementations MUST NOT negotiate SSL version 2. 188 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 190 o Implementations MUST NOT negotiate SSL version 3. 192 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 193 plugged some significant security holes, but did not support 194 strong cipher suites. SSLv3 does not support TLS extensions, some 195 of which (e.g., renegotiation_info) are security-critical. In 196 addition, with the emergence of the POODLE attack [POODLE], SSLv3 197 is now widely recognized as fundamentally insecure. 199 o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]. 201 Rationale: TLS 1.0 (published in 1999) does not support many 202 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 203 record IV for CBC-based cipher suites and does not warn against 204 common padding errors. 206 o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346]. 208 Rationale: TLS 1.1 (published in 2006) is a security improvement 209 over TLS 1.0, but still does not support certain stronger cipher 210 suites. 212 o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to 213 negotiate TLS version 1.2 over earlier versions of TLS. 215 Rationale: Several stronger cipher suites are available only with 216 TLS 1.2 (published in 2008). In fact, the cipher suites 217 recommended by this document (Section 4.2 below) are only 218 available in TLS 1.2. 220 This BCP applies to TLS 1.2. It is not safe for readers to assume 221 that the recommendations in this BCP apply to any future version of 222 TLS. 224 3.1.2. DTLS Protocol Versions 226 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 227 1.1 was published. The following are the recommendations with 228 respect to DTLS: 230 o Implementations MAY negotiate DTLS version 1.0 [RFC4347]. 232 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 234 o Implementations MUST support, and prefer to negotiate, DTLS 235 version 1.2 [RFC6347]. 237 Version 1.2 of DTLS correlates to Version 1.2 of TLS 1.2 (see 238 above). (There is no Version 1.1 of DTLS.) 240 3.1.3. Fallback to Lower Versions 242 Clients that "fall back" to lower versions of the protocol after the 243 server rejects higher versions of the protocol MUST NOT fall back to 244 SSLv3. 246 Rationale: Some client implementations revert to lower versions of 247 TLS or even to SSLv3 if the server rejected higher versions of the 248 protocol. This fallback can be forced by a man in the middle (MITM) 249 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 250 1.2, the version recommended by this document. While TLS 1.0-only 251 servers are still quite common, IP scans show that SSLv3-only servers 252 amount to only about 3% of the current Web server population. (At 253 the time of this writing, an explicit method for preventing downgrade 254 attacks is being defined in [I-D.ietf-tls-downgrade-scsv].) 256 3.2. Strict TLS 258 To prevent SSL Stripping: 260 o In cases where an application protocol allows implementations or 261 deployments a choice between strict TLS configuration and dynamic 262 upgrade from unencrypted to TLS-protected traffic (such as 263 STARTTLS), clients and servers SHOULD prefer strict TLS 264 configuration. 266 o In many application protocols, clients can be configured to use 267 TLS no matter whether the server offers TLS during a protocol 268 exchange or advertises support for TLS (e.g., through a flag 269 indicating that TLS is required). Application clients SHOULD use 270 TLS by default, and disable this default only through explicit 271 configuration by the user. 273 o HTTP client and server implementations MUST support the HTTP 274 Strict Transport Security (HSTS) header [RFC6797], in order to 275 allow Web servers to advertise that they are willing to accept 276 TLS-only clients. 278 o When applicable, Web servers SHOULD use HSTS to indicate that they 279 are willing to accept TLS-only clients. 281 Rationale: Combining unprotected and TLS-protected communication 282 opens the way to SSL Stripping and similar attacks, since an initial 283 part of the communication is not integrity protected and therefore 284 can be manipulated by an attacker whose goal is to keep the 285 communication in the clear. 287 3.3. Compression 289 Implementations and deployments SHOULD disable TLS-level compression 290 ([RFC5246], Section 6.2.2). 292 Rationale: TLS compression has been subject to security attacks, such 293 as the CRIME attack. 295 Implementers should note that compression at higher protocol levels 296 can allow an active attacker to extract cleartext information from 297 the connection. The BREACH attack is one such case. These issues 298 can only be mitigated outside of TLS and are thus out of scope of the 299 current document. See Section 2.6 of [I-D.ietf-uta-tls-attacks] for 300 further details. 302 3.4. TLS Session Resumption 304 If TLS session resumption is used, care ought to be taken to do so 305 safely. In particular, when using session tickets [RFC5077], the 306 resumption information MUST be authenticated and encrypted to prevent 307 modification or eavesdropping by an attacker. Further 308 recommendations apply to session tickets: 310 o A strong cipher suite MUST be used when encrypting the ticket (as 311 least as strong as the main TLS cipher suite). 313 o Ticket keys MUST be changed regularly, e.g., once every week, so 314 as not to negate the benefits of forward secrecy (see Section 7.3 315 for details on forward secrecy). 317 o For similar reasons, session ticket validity SHOULD be limited to 318 a reasonable duration (e.g., half as long as ticket key validity). 320 Rationale: session resumption is another kind of TLS handshake, and 321 therefore must be as secure as the initial handshake. This document 322 (Section 4) recommends the use of cipher suites that provide forward 323 secrecy, i.e. that prevent an attacker who gains momentary access to 324 the TLS endpoint (either client or server) and its secrets from 325 reading either past or future communication. The tickets must be 326 managed so as not to negate this security property. 328 3.5. TLS Renegotiation 330 Where handshake renegotiation is implemented, both clients and 331 servers MUST implement the renegotiation_info extension, as defined 332 in [RFC5746]. 334 To counter the Triple Handshake attack, we adopt the recommended 335 countermeasures from [triple-handshake]: TLS clients SHOULD apply the 336 same validation policy for all certificates received over a 337 connection, bind the master secret to the full handshake, and bind 338 the abbreviated session resumption handshake to the original full 339 handshake. In some usages, it may be simplest to refuse any change 340 of certificates during renegotiation. 342 3.6. Server Name Indication 344 TLS implementations MUST support the Server Name Indication (SNI) 345 extension for those higher level protocols which would benefit from 346 it, including HTTPS. However, unlike implementation, the use of SNI 347 in particular circumstances is a matter of local policy. 349 Rationale: SNI supports deployment of multiple TLS-protected virtual 350 servers on a single address, and therefore enables fine-grained 351 security for these virtual servers, by allowing each one to have its 352 own certificate. 354 4. Recommendations: Cipher Suites 356 TLS and its implementations provide considerable flexibility in the 357 selection of cipher suites. Unfortunately, some available cipher 358 suites are insecure, some do not provide the targeted security 359 services, and some no longer provide enough security. Incorrectly 360 configuring a server leads to no or reduced security. This section 361 includes recommendations on the selection and negotiation of cipher 362 suites. 364 4.1. General Guidelines 366 Cryptographic algorithms weaken over time as cryptanalysis improves. 367 In other words, as time progresses, algorithms that were once 368 considered strong but are now weak, need to be phased out over time 369 and replaced with more secure cipher suites to ensure that desired 370 security properties still hold. SSL/TLS has been in existence for 371 almost 20 years at this point and this section provides some much 372 needed recommendations concerning cipher suite selection: 374 o Implementations MUST NOT negotiate the cipher suites with NULL 375 encryption. 377 Rationale: The NULL cipher suites do not encrypt traffic and so 378 provide no confidentiality services. Any entity in the network 379 with access to the connection can view the plaintext of contents 380 being exchanged by the client and server. 382 o Implementations MUST NOT negotiate RC4 cipher suites. 384 Rationale: The RC4 stream cipher has a variety of cryptographic 385 weaknesses, as documented in [I-D.ietf-tls-prohibiting-rc4]. We 386 note that this guideline does not apply to DTLS, which 387 specifically forbids the use of RC4. 389 o Implementations MUST NOT negotiate cipher suites offering less 390 than 112 bits of security, including the so-called "export-level" 391 encryption (which provide 40 or 56 bits of security). 393 Rationale: Based on [RFC3766], at least 112 bits of security is 394 needed. 40-bit and 56-bit security are considered insecure today. 395 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. 397 o Implementations SHOULD NOT negotiate cipher suites that use 398 algorithms offering less than 128 bits of security. 400 Rationale: Cipher suites that offer between 112-bits and 128-bits 401 of security are not considered weak at this time, however it is 402 expected that their useful lifespan is short enough to justify 403 supporting stronger cipher suites at this time. 128-bit ciphers 404 are expected to remain secure for at least several years, and 405 256-bit ciphers "until the next fundamental technology 406 breakthrough". Note that some legacy cipher suites (e.g., 168-bit 407 3DES) have an effective key length which is smaller than their 408 nominal key length (112 bits in the case of 3DES). Such cipher 409 suites should be evaluated according to their effective key 410 length. 412 o Implementations MUST support, and SHOULD prefer to negotiate, 413 cipher suites offering forward secrecy, such as those in the 414 Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie- 415 Hellman ("DHE" and "ECDHE") families. 417 Rationale: Forward secrecy (sometimes called "perfect forward 418 secrecy") prevents the recovery of information that was encrypted 419 with older session keys, thus limiting the amount of time during 420 which attacks can be successful. See Section 7.3 for a detailed 421 discussion. 423 4.2. Recommended Cipher Suites 425 Given the foregoing considerations, implementation and deployment of 426 the following cipher suites is RECOMMENDED: 428 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 429 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 431 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 433 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 435 These cipher suites are supported only in TLS 1.2 because they are 436 authenticated encryption (AEAD) algorithms [RFC5116]. 438 Typically, in order to prefer these suites, the order of suites needs 439 to be explicitly configured in server software. 441 Some devices have hardware support for AES-CCM but not AES-GCM. 442 There are even devices that do not support public key cryptography at 443 all. This BCP does not cover such devices. 445 4.2.1. Implementation Details 447 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 448 first proposal to any server, unless they have prior knowledge that 449 the server cannot respond to a TLS 1.2 client_hello message. 451 Servers SHOULD prefer this cipher suite whenever it is proposed, even 452 if it is not the first proposal. 454 Clients are of course free to offer stronger cipher suites, e.g., 455 using AES-256; when they do, the server SHOULD prefer the stronger 456 cipher suite unless there are compelling reasons (e.g., seriously 457 degraded performance) to choose otherwise. 459 This document does not change the mandatory-to-implement TLS cipher 460 suite(s) prescribed by TLS or application protocols using TLS. To 461 maximize interoperability, RFC 5246 mandates implementation of the 462 TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly 463 weaker than the cipher suites recommended here. Implementers should 464 consider the interoperability gain against the loss in security when 465 deploying that cipher suite. Other application protocols specify 466 other cipher suites as mandatory to implement (MTI). 468 Note that some profiles of TLS 1.2 use different cipher suites. For 469 example, [RFC6460] defines a profile that uses the 470 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 471 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 473 [RFC4492] allows clients and servers to negotiate ECDH parameters 474 (curves). Both clients and servers SHOULD include the "Supported 475 Elliptic Curves" extension [RFC4492]. For interoperability, clients 476 and servers SHOULD support the NIST P-256 (secp256r1) curve 478 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 479 extension with a single element, "uncompressed". 481 4.3. Public Key Length 483 When using the cipher suites recommended in this document, two public 484 keys are normally used in the TLS handshake: one for the Diffie- 485 Hellman key agreement and one for server authentication. Where a 486 client certificate is used, a third public key is added. 488 With a key exchange based on modular Diffie-Hellman ("DHE" cipher 489 suites), DH key lengths of at least 2048 bits are RECOMMENDED. 491 Rationale: For various reasons, in practice DH keys are typically 492 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 493 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 494 would be roughly equivalent to only an 80-bit symmetric key 495 [RFC3766], it is better to use keys longer than that for the "DHE" 496 family of cipher suites. A DH key of 1926 bits would be roughly 497 equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048 498 bits might be sufficient for at least the next 10 years. See 499 Section 4.4 for additional information on the use of modular Diffie- 500 Hellman in TLS. 502 As noted in [RFC3766], correcting for the emergence of a TWIRL 503 machine would imply that 1024-bit DH keys yield about 65 bits of 504 equivalent strength and that a 2048-bit DH key would yield about 92 505 bits of equivalent strength. 507 With regard to ECDH keys, the IANA named curve registry contains 508 160-bit elliptic curves which are considered to be roughly equivalent 509 to only an 80-bit symmetric key [ECRYPT-II]. The use of curves of 510 less than 192-bits is NOT RECOMMENDED. 512 When using RSA servers SHOULD authenticate using certificates with at 513 least a 2048-bit modulus for the public key. In addition, the use of 514 the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for 515 more details). Clients SHOULD indicate to servers that they request 516 SHA-256, by using the "Signature Algorithms" extension defined in 517 TLS 1.2. 519 4.4. Modular vs. Elliptic Curve DH Cipher Suites 521 Not all TLS implementations support both modular and elliptic curve 522 Diffie-Hellman groups, as required by Section 4.2. Some 523 implementations are severely limited in the length of DH values. 524 When such implementations need to be accommodated, we recommend using 525 (in priority order): 527 1. Elliptic Curve DHE with negotiated parameters [RFC5289] 529 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 530 Diffie-Hellman parameters 532 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters. 534 Rationale: Although Elliptic Curve Cryptography is widely deployed 535 there are some communities where its uptake has been limited for 536 several reasons, including its complexity compared to modular 537 arithmetic and longstanding perceptions of IPR concerns (which, for 538 the most part, have now been resolved [RFC6090]). Note that ECDHE 539 cipher suites exist for both RSA and ECDSA certificates so moving to 540 ECDHE cipher suites does not require moving away from RSA based 541 certificates. On the other hand, there are two related issues 542 hindering effective use of modular Diffie-Hellman cipher suites in 543 TLS: 545 o There are no standardized, widely implemented protocol mechanisms 546 to negotiate the DH groups or parameter lengths supported by 547 client and server. 549 o Many servers choose DH parameters of 1024 bits or fewer. 551 o There are widely deployed client implementations that reject 552 received DH parameters if they are longer than 1024 bits. In 553 addition, several implementations do not perform appropriate 554 validation of group parameters and are vulnerable to attacks 555 referenced in Section 2.9 of [I-D.ietf-uta-tls-attacks] 557 We note that with DHE and ECDHE cipher suites, the TLS master key 558 only depends on the Diffie-Hellman parameters and not on the strength 559 of the RSA certificate; moreover, 1024 bit modular DH parameters are 560 generally considered insufficient at this time. 562 With modular ephemeral DH, deployers SHOULD carefully evaluate 563 interoperability vs. security considerations when configuring their 564 TLS endpoints. 566 4.5. Truncated HMAC 568 Implementations MUST NOT use the Truncated HMAC extension, defined in 569 Section 7 of [RFC6066]. 571 Rationale: the extension does not apply to the AEAD cipher suites 572 recommended above. However it does apply to most other TLS cipher 573 suites. Its use has been shown to be insecure in [PatersonRS11]. 575 5. Applicability Statement 577 The deployment recommendations of this document address the operators 578 of application layer services that are most commonly used on the 579 Internet, including, but not limited to: 581 o Operators of web servers that wish to protect HTTP with TLS. 583 o Operators of email servers who wish to protect the application- 584 layer protocols with TLS (e.g., IMAP, POP3 or SMTP). 586 o Operators of instant-messaging services who wish to protect their 587 application-layer protocols with TLS (e.g., XMPP or IRC). 589 5.1. Security Services 591 This document provides recommendations for an audience that wishes to 592 secure their communication with TLS to achieve the following: 594 o Confidentiality: all application-layer communication is encrypted 595 with the goal that no party should be able to decrypt it except 596 the intended receiver. 598 o Data integrity: any changes made to the communication in transit 599 are detectable by the receiver. 601 o Authentication: an end-point of the TLS communication is 602 authenticated as the intended entity to communicate with. 604 With regard to authentication, TLS enables authentication of one or 605 both end-points in the communication. Although some TLS usage 606 scenarios do not require authentication, those scenarios are not in 607 scope for this document (a rationale for this decision is provided 608 under Section 5.2). 610 If deployers deviate from the recommendations given in this document, 611 they MUST verify that they do not need one of the foregoing security 612 services. 614 This document applies only to environments where confidentiality is 615 required. It recommends algorithms and configuration options that 616 enforce secrecy of the data-in-transit. 618 This document also assumes that data integrity protection is always 619 one of the goals of a deployment. In cases where integrity is not 620 required, it does not make sense to employ TLS in the first place. 621 There are attacks against confidentiality-only protection that 622 utilize the lack of integrity to also break confidentiality (see for 623 instance [DegabrieleP07] in the context of IPsec). 625 The intended audience covers those services that are most commonly 626 used on the Internet. Typically, all communication between TLS 627 clients and TLS servers requires all three of the above security 628 services. This is particularly true where TLS clients are user 629 agents like Web browsers or email software. 631 This document does not address the rarer deployment scenarios where 632 one of the above three properties is not desired, such as the use 633 case described under Section 5.2 below. Another example of an 634 audience not needing confidentiality is the following: a monitored 635 network where the authorities in charge of the respective traffic 636 domain require full access to unencrypted (plaintext) traffic, and 637 where users collaborate and send their traffic in the clear. 639 5.2. Unauthenticated TLS and Opportunistic Security 641 Several important applications use TLS to protect data between a TLS 642 client and a TLS server, but do so without the TLS client necessarily 643 verifying the server's certificate. This practice is often called 644 "unauthenticated TLS". The reader is referred to 645 [I-D.ietf-dane-smtp-with-dane] for an example and an explanation of 646 why this less secure practice will likely remain common in the 647 context of SMTP (especially for MTA-to-MTA communications). The 648 practice is also encountered in similar contexts such as server-to- 649 server traffic on the XMPP network (where multi-tenant hosting 650 environments make it difficult for operators to obtain proper 651 certificates for all of the domains they service). 653 Furthermore, in some scenarios the use of TLS itself is optional, 654 i.e. the client decides dynamically ("opportunistically") whether to 655 use TLS with a particular server or to connect in the clear. This 656 practice, often called "opportunistic security", and is described at 657 length in Section 2 of [I-D.farrelll-mpls-opportunistic-encrypt]. 659 It can be argued that the recommendations provided in this document 660 ought to apply equally to unauthenticated TLS as well as 661 authenticated TLS. That would keep TLS implementations and 662 deployments in sync, which is a desirable property given that servers 663 can be used simultaneously for unauthenticated TLS and for 664 authenticated TLS (indeed, a server cannot know whether a client 665 might attempt authenticated or unauthenticated TLS). On the other 666 hand, it has been argued that some of the recommendations in this 667 document might be too strict for unauthenticated scenarios and that 668 any security is better than no security at all (i.e., sending traffic 669 in the clear), even if it means deploying outdated protocol versions 670 and ciphers in unauthenticated scenarios. The sense of the UTA 671 Working Group was to complete work on this document about 672 authenticated TLS and to initiate work on a separate document about 673 unauthenticated TLS. 675 In summary: this document does not apply to unauthenticated TLS use 676 cases. 678 6. IANA Considerations 680 This document requests no actions of IANA. [Note to RFC Editor: 681 please remove this whole section before publication.] 683 7. Security Considerations 685 This entire document discusses the security practices directly 686 affecting applications using the TLS protocol. This section contains 687 broader security considerations related to technologies used in 688 conjunction with or by TLS. 690 7.1. Host Name Validation 692 Application authors should take note that TLS implementations 693 frequently do not validate host names and must therefore determine if 694 the TLS implementation they are using does and, if not, write their 695 own validation code or consider changing the TLS implementation. 697 It is noted that the requirements regarding host name validation (and 698 in general, binding between the TLS layer and the protocol that runs 699 above it) vary between different protocols. For HTTPS, these 700 requirements are defined by Section 3 of [RFC2818]. 702 Readers are referred to [RFC6125] for further details regarding 703 generic host name validation in the TLS context. In addition, the 704 RFC contains a long list of example protocols, some of which 705 implement a policy very different from HTTPS. 707 If the host name is discovered indirectly and in an insecure manner 708 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 709 NOT be used as a reference identifier [RFC6125] even when it matches 710 the presented certificate. This proviso does not apply if the host 711 name is discovered securely (for further discussion, see for example 712 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]). 714 Host name validation typically applies only to the leaf "end entity" 715 certificate. Naturally, in order to ensure proper authentication in 716 the context of the PKI, application clients need to verify the entire 717 certification path in accordance with [RFC5280] (see also [RFC6125]). 719 7.2. AES-GCM 721 Section 4.2 above recommends the use of the AES-GCM authenticated 722 encryption algorithm. Please refer to [RFC5246], Section 11 for 723 general security considerations when using TLS 1.2, and to [RFC5288], 724 Section 6 for security considerations that apply specifically to AES- 725 GCM when used with TLS. 727 7.3. Forward Secrecy 729 Forward secrecy (also often called Perfect Forward Secrecy or "PFS" 730 and defined in [RFC4949]) is a defense against an attacker who 731 records encrypted conversations where the session keys are only 732 encrypted with the communicating parties' long-term keys. Should the 733 attacker be able to obtain these long-term keys at some point later 734 in time, he will be able to decrypt the session keys and thus the 735 entire conversation. In the context of TLS and DTLS, such compromise 736 of long-term keys is not entirely implausible. It can happen, for 737 example, due to: 739 o A client or server being attacked by some other attack vector, and 740 the private key retrieved. 742 o A long-term key retrieved from a device that has been sold or 743 otherwise decommissioned without prior wiping. 745 o A long-term key used on a device as a default key [Heninger2012]. 747 o A key generated by a Trusted Third Party like a CA, and later 748 retrieved from it either by extortion or compromise 749 [Soghoian2011]. 751 o A cryptographic break-through, or the use of asymmetric keys with 752 insufficient length [Kleinjung2010]. 754 o Social engineering attacks against system administrators. 756 o Collection of private keys from inadequately protected backups. 758 Forward secrecy ensures in such cases that the session keys cannot be 759 determined even by an attacker who obtains the long-term keys some 760 time after the conversation. It also protects against an attacker 761 who is in possession of the long-term keys, but remains passive 762 during the conversation. 764 Forward secrecy is generally achieved by using the Diffie-Hellman 765 scheme to derive session keys. The Diffie-Hellman scheme has both 766 parties maintain private secrets and send parameters over the network 767 as modular powers over certain cyclic groups. The properties of the 768 so-called Discrete Logarithm Problem (DLP) allow to derive the 769 session keys without an eavesdropper being able to do so. There is 770 currently no known attack against DLP if sufficiently large 771 parameters are chosen. A variant of the Diffie-Hellman scheme uses 772 Elliptic Curves instead of the originally proposed modular 773 arithmetics. 775 Unfortunately, many TLS/DTLS cipher suites were defined that do not 776 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. We 777 thus advocate strict use of forward-secrecy-only ciphers. 779 7.4. Diffie-Hellman Exponent Reuse 781 For performance reasons, many TLS implementations reuse Diffie- 782 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 783 connections. Such reuse can result in major security issues: 785 o If exponents are reused for a long time (e.g., more than a few 786 hours), an attacker who gains access to the host can decrypt 787 previous connections. In other words, exponent reuse negates the 788 effects of forward secrecy. 790 o TLS implementations that reuse exponents should test the DH public 791 key they receive for group membership, in order to avoid some 792 known attacks. These tests are not standardized in TLS at the 793 time of writing. See [RFC6989] for recipient tests required of 794 IKEv2 implementations that reuse DH exponents. 796 7.5. Certificate Revocation 798 Unfortunately, no mechanism exists at this time that we can recommend 799 as a complete and efficient solution for the problem of checking the 800 revocation status of common public key certificates (a.k.a. PKIX 801 certificates, [RFC5280]). The current state of the art is as 802 follows: 804 o Although Certificate Revocation Lists (CRLs) are the most widely 805 supported mechanism for distributing revocation information, they 806 have known scaling challenges that limit their usefulness (despite 807 workarounds such as partitioned CRLS and delta CRLs). 809 o Proprietary mechanisms that embed revocation lists in the Web 810 browser's configuration database cannot scale beyond a small 811 number of the most heavily used Web servers. 813 o The On-Line Certification Status Protocol (OCSP) [RFC6960] 814 presents both scaling and privacy issues. In addition, clients 815 typically "soft-fail", meaning that they do not abort the TLS 816 connection if the OCSP server does not respond (however, this 817 might be a workaround to avoid denial of service attacks if an 818 OSCP responder is taken offline). 820 o OCSP stapling (Section 8 of [RFC6066]) resolves the operational 821 issues with OCSP, but is still ineffective in the presence of a 822 MITM attacker because the attacker can simply ignore the client's 823 request for a stapled OCSP response. 825 o OCSP stapling as defined in [RFC6066] does not extend to 826 intermediate certificates used in a certificate chain. Although 827 [RFC6961] addresses this shortcoming, it is a recent addition 828 without much deployment. 830 o Both CRLs and OSCP depend on relatively reliable connectivity to 831 the Internet, which might not be available to certain kinds of 832 nodes (such as newly provisioned devices that need to establish a 833 secure connection in order to boot up for the first time). 835 With regard to PKIX certificates, servers SHOULD support both OCSP 836 [RFC6960] and OCSP stapling. To enable interoperability with the 837 widest range of clients, servers SHOULD support both the 838 status_request extension defined in [RFC6066] and the 839 status_request_v2 extension defined in [RFC6961]. Servers also 840 SHOULD support the OCSP stapling extension defined in [RFC6961] as a 841 best practice given the current state of the art and as a foundation 842 for a possible future solution. 844 The foregoing considerations do not apply to scenarios where the 845 DANE-TLSA resource record [RFC6698] is used to signal to a client 846 which certificate a server considers valid and good to use for TLS 847 connections. 849 8. Acknowledgments 851 We would like to thank Uri Blumenthal, Viktor Dukhovni, Stephen 852 Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson 853 Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, 854 Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom 855 Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean 856 Turner, and Aaron Zauner for their feedback and suggested 857 improvements. Thanks to Brian Smith, who has provided a great 858 resource in his "Proposal to Change the Default TLS Ciphersuites 859 Offered by Browsers" [Smith2013]. Finally, thanks to all others who 860 commented on the TLS, UTA, and other discussion lists but who are not 861 mentioned here by name. 863 9. References 865 9.1. Normative References 867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, March 1997. 870 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 872 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 873 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 874 RFC 3766, April 2004. 876 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 877 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 878 for Transport Layer Security (TLS)", RFC 4492, May 2006. 880 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 881 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 883 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 884 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 885 August 2008. 887 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 888 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 889 August 2008. 891 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 892 "Transport Layer Security (TLS) Renegotiation Indication 893 Extension", RFC 5746, February 2010. 895 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 896 Verification of Domain-Based Application Service Identity 897 within Internet Public Key Infrastructure Using X.509 898 (PKIX) Certificates in the Context of Transport Layer 899 Security (TLS)", RFC 6125, March 2011. 901 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 902 (SSL) Version 2.0", RFC 6176, March 2011. 904 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 905 Security Version 1.2", RFC 6347, January 2012. 907 9.2. Informative References 909 [CAB-Baseline] 910 CA/Browser Forum, , "Baseline Requirements for the 911 Issuance and Management of Publicly-Trusted Certificates 912 Version 1.1.6", 2013, . 915 [DegabrieleP07] 916 Degabriele, J. and K. Paterson, "Attacking the IPsec 917 standards in encryption-only configurations", 2007, 918 . 920 [ECRYPT-II] 921 Smart, N., "ECRYPT II Yearly Report on Algorithms and 922 Keysizes (2011-2012)", 2012, 923 . 925 [Heninger2012] 926 Heninger, N., Durumeric, Z., Wustrow, E., and J. 927 Halderman, "Mining Your Ps and Qs: Detection of Widespread 928 Weak Keys in Network Devices", Usenix Security Symposium 929 2012, 2012. 931 [I-D.farrelll-mpls-opportunistic-encrypt] 932 Farrel, A. and S. Farrell, "Opportunistic Encryption in 933 MPLS Networks", draft-farrelll-mpls-opportunistic- 934 encrypt-02 (work in progress), February 2014. 936 [I-D.ietf-dane-smtp-with-dane] 937 Dukhovni, V. and W. Hardaker, "SMTP security via 938 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 939 (work in progress), May 2014. 941 [I-D.ietf-dane-srv] 942 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 943 Based Authentication of Named Entities (DANE) TLSA Records 944 with SRV Records", draft-ietf-dane-srv-06 (work in 945 progress), June 2014. 947 [I-D.ietf-tls-downgrade-scsv] 948 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 949 Suite Value (SCSV) for Preventing Protocol Downgrade 950 Attacks", draft-ietf-tls-downgrade-scsv-02 (work in 951 progress), November 2014. 953 [I-D.ietf-tls-prohibiting-rc4] 954 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 955 tls-prohibiting-rc4-01 (work in progress), October 2014. 957 [I-D.ietf-uta-tls-attacks] 958 Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 959 Current Attacks on TLS and DTLS", draft-ietf-uta-tls- 960 attacks-04 (work in progress), September 2014. 962 [Kleinjung2010] 963 Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", 964 CRYPTO 10, 2010, . 966 [POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE 967 Bites: Exploiting the SSL 3.0 Fallback", 2014, . 970 [PatersonRS11] 971 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size 972 does matter: attacks and proofs for the TLS record 973 protocol", 2011, 974 . 976 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 977 RFC 2246, January 1999. 979 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 980 Algorithm and Its Use with IPsec", RFC 3602, September 981 2003. 983 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 984 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 986 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 987 Security", RFC 4347, April 2006. 989 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 990 4949, August 2007. 992 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 993 "Transport Layer Security (TLS) Session Resumption without 994 Server-Side State", RFC 5077, January 2008. 996 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 997 Encryption", RFC 5116, January 2008. 999 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1000 Housley, R., and W. Polk, "Internet X.509 Public Key 1001 Infrastructure Certificate and Certificate Revocation List 1002 (CRL) Profile", RFC 5280, May 2008. 1004 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1005 Extension Definitions", RFC 6066, January 2011. 1007 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1008 Curve Cryptography Algorithms", RFC 6090, February 2011. 1010 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1011 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1012 August 2011. 1014 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 1015 Layer Security (TLS)", RFC 6460, January 2012. 1017 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1018 of Named Entities (DANE) Transport Layer Security (TLS) 1019 Protocol: TLSA", RFC 6698, August 2012. 1021 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1022 Transport Security (HSTS)", RFC 6797, November 2012. 1024 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1025 Galperin, S., and C. Adams, "X.509 Internet Public Key 1026 Infrastructure Online Certificate Status Protocol - OCSP", 1027 RFC 6960, June 2013. 1029 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1030 Multiple Certificate Status Request Extension", RFC 6961, 1031 June 2013. 1033 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 1034 Tests for the Internet Key Exchange Protocol Version 2 1035 (IKEv2)", RFC 6989, July 2013. 1037 [Smith2013] 1038 Smith, B., "Proposal to Change the Default TLS 1039 Ciphersuites Offered by Browsers.", 2013, . 1042 [Soghoian2011] 1043 Soghoian, C. and S. Stamm, "Certified lies: Detecting and 1044 defeating government interception attacks against SSL.", 1045 Proc. 15th Int. Conf. Financial Cryptography and Data 1046 Security , 2011. 1048 [triple-handshake] 1049 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 1050 "Triple Handshakes Considered Harmful: Breaking and Fixing 1051 Authentication over TLS", 2014, . 1054 Appendix A. Change Log 1056 Note to RFC Editor: please remove this section before publication. 1058 A.1. draft-ietf-uta-tls-bcp-08 1060 o More WGLC feedback. 1062 o TLS 1.1 is now SHOULD NOT, just like TLS 1.0. 1064 o SHOULD NOT use curves of less than 192 bits for ECDH. 1066 o Clarification regarding OCSP and OSCP stapling. 1068 A.2. draft-ietf-uta-tls-bcp-07 1070 o WGLC feedback. 1072 A.3. draft-ietf-uta-tls-bcp-06 1074 o Undo unauthenticated TLS, following another long thread on the 1075 list. 1077 A.4. draft-ietf-uta-tls-bcp-05 1079 o Lots of comments by Sean Turner. 1081 o Unauthenticated TLS, following a long thread on the list. 1083 A.5. draft-ietf-uta-tls-bcp-04 1085 o Some cleanup, and input from TLS WG discussion on applicability. 1087 A.6. draft-ietf-uta-tls-bcp-03 1089 o Disallow truncated HMAC. 1091 o Applicability to DTLS. 1093 o Some more text restructuring. 1095 o Host name validation is sometimes irrelevant. 1097 o HSTS: MUST implement, SHOULD deploy. 1099 o Session identities are not protected, only tickets are. 1101 o Clarified the target audience. 1103 A.7. draft-ietf-uta-tls-bcp-02 1105 o Rearranged some sections for clarity and re-styled the text so 1106 that normative text is followed by rationale where possible. 1108 o Removed the recommendation to use Brainpool curves. 1110 o Triple Handshake mitigation. 1112 o MUST NOT negotiate algorithms lower than 112 bits of security. 1114 o MUST implement SNI, but use per local policy. 1116 o Changed SHOULD NOT negotiate or fall back to SSLv3 to MUST NOT. 1118 o Added hostname validation. 1120 o Non-normative discussion of DH exponent reuse. 1122 A.8. draft-ietf-tls-bcp-01 1124 o Clarified that specific TLS-using protocols may have stricter 1125 requirements. 1127 o Changed TLS 1.0 from MAY to SHOULD NOT. 1129 o Added discussion of "optional TLS" and HSTS. 1131 o Recommended use of the Signature Algorithm and Renegotiation Info 1132 extensions. 1134 o Use of a strong cipher for a resumption ticket: changed SHOULD to 1135 MUST. 1137 o Added an informational discussion of certificate revocation, but 1138 no recommendations. 1140 A.9. draft-ietf-tls-bcp-00 1142 o Initial WG version, with only updated references. 1144 A.10. draft-sheffer-tls-bcp-02 1146 o Reorganized the content to focus on recommendations. 1148 o Moved description of attacks to a separate document (draft- 1149 sheffer-uta-tls-attacks). 1151 o Strengthened recommendations regarding session resumption. 1153 A.11. draft-sheffer-tls-bcp-01 1155 o Clarified our motivation in the introduction. 1157 o Added a section justifying the need for forward secrecy. 1159 o Added recommendations for RSA and DH parameter lengths. Moved 1160 from DHE to ECDHE, with a discussion on whether/when DHE is 1161 appropriate. 1163 o Recommendation to avoid fallback to SSLv3. 1165 o Initial information about browser support - more still needed! 1167 o More clarity on compression. 1169 o Client can offer stronger cipher suites. 1171 o Discussion of the regular TLS mandatory cipher suite. 1173 A.12. draft-sheffer-tls-bcp-00 1175 o Initial version. 1177 Authors' Addresses 1179 Yaron Sheffer 1180 Porticor 1181 29 HaHarash St. 1182 Hod HaSharon 4501303 1183 Israel 1185 Email: yaronf.ietf@gmail.com 1186 Ralph Holz 1187 Technische Universitaet Muenchen 1188 Boltzmannstr. 3 1189 Garching 85748 1190 Germany 1192 Email: ralph.ietf@gmail.com 1194 Peter Saint-Andre 1195 &yet 1197 Email: peter@andyet.com 1198 URI: https://andyet.com/