idnits 2.17.1 draft-ietf-uta-rfc7525bis-03.txt: -(1268): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC7525, but the abstract doesn't seem to directly say this. It does mention RFC7525 though, so this could be OK. -- The draft header indicates that this document updates RFC6066, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5288, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5288, updated by this document, for RFC5378 checks: 2007-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 October 2021) is 914 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7507 (Obsoleted by RFC 8996) ** Obsolete normative reference: RFC 8740 (Obsoleted by RFC 9113) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-13 == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-aead-limits-03 -- 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) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Obsoletes: 7525 (if approved) R. Holz 5 Updates: 5288, 6066 (if approved) University of Twente 6 Intended status: Best Current Practice P. Saint-Andre 7 Expires: 28 April 2022 Mozilla 8 T. Fossati 9 arm 10 25 October 2021 12 Recommendations for Secure Use of Transport Layer Security (TLS) and 13 Datagram Transport Layer Security (DTLS) 14 draft-ietf-uta-rfc7525bis-03 16 Abstract 18 Transport Layer Security (TLS) and Datagram Transport Layer Security 19 (DTLS) are widely used to protect data exchanged over application 20 protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the 21 last few years, several serious attacks on TLS have emerged, 22 including attacks on its most commonly used cipher suites and their 23 modes of operation. This document provides recommendations for 24 improving the security of deployed services that use TLS and DTLS. 25 The recommendations are applicable to the majority of use cases. 27 This document was published as RFC 7525 when the industry was in the 28 midst of its transition to TLS 1.2. Years later this transition is 29 largely complete and TLS 1.3 is widely available. Given the new 30 environment, we believe new guidance is needed. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 28 April 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. General Recommendations . . . . . . . . . . . . . . . . . . . 5 68 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5 70 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6 71 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7 72 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8 75 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9 76 3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 9 77 3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10 78 3.8. Application-Layer Protocol Negotiation . . . . . . . . . 10 79 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11 80 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 11 81 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 11 82 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 13 83 4.2.1. Implementation Details . . . . . . . . . . . . . . . 13 84 4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14 85 4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 14 86 4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15 87 4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16 88 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16 89 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17 90 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18 93 6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19 95 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20 96 6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21 97 6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22 98 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 101 8.2. Informative References . . . . . . . . . . . . . . . . . 26 102 Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32 103 Appendix B. Document History . . . . . . . . . . . . . . . . . . 33 104 B.1. draft-ietf-uta-rfc7525bis-03 . . . . . . . . . . . . . . 33 105 B.2. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33 106 B.3. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33 107 B.4. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34 108 B.5. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34 109 B.6. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 112 1. Introduction 114 Transport Layer Security (TLS) [RFC5246] and Datagram Transport 115 Security Layer (DTLS) [RFC6347] are widely used to protect data 116 exchanged over application protocols such as HTTP, SMTP, IMAP, POP, 117 SIP, and XMPP. Over the years leading to 2015, several serious 118 attacks on TLS have emerged, including attacks on its most commonly 119 used cipher suites and their modes of operation. For instance, both 120 the AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms, which 121 together have been the most widely deployed ciphers, have been 122 attacked in the context of TLS. A companion document [RFC7457] 123 provides detailed information about these attacks and will help the 124 reader understand the rationale behind the recommendations provided 125 here. 127 The TLS community reacted to these attacks in two ways: 129 * Detailed guidance was published on the use of TLS 1.2 and earlier 130 protocol versions. This guidance is included in the original 131 [RFC7525] and mostly retained in this revised version. 133 * A new protocol version was released, TLS 1.3 [RFC8446], which 134 largely mitigates or resolves these attacks. 136 Those who implement and deploy TLS and DTLS, in particular versions 137 1.2 or earlier of these protocols, need guidance on how TLS can be 138 used securely. This document provides guidance for deployed services 139 as well as for software implementations, assuming the implementer 140 expects his or her code to be deployed in environments defined in 141 Section 5. Concerning deployment, this document targets a wide 142 audience -- namely, all deployers who wish to add authentication (be 143 it one-way only or mutual), confidentiality, and data integrity 144 protection to their communications. 146 The recommendations herein take into consideration the security of 147 various mechanisms, their technical maturity and interoperability, 148 and their prevalence in implementations at the time of writing. 149 Unless it is explicitly called out that a recommendation applies to 150 TLS alone or to DTLS alone, each recommendation applies to both TLS 151 and DTLS. 153 This document attempts to minimize new guidance to TLS 1.2 154 implementations, and the overall approach is to encourage systems to 155 move to TLS 1.3. However this is not always practical. Newly 156 discovered attacks, as well as ecosystem changes, necessitated some 157 new requirements that apply to TLS 1.2 environments. Those are 158 summarized in Appendix A. 160 As noted, the TLS 1.3 specification resolves many of the 161 vulnerabilities listed in this document. A system that deploys TLS 162 1.3 should have fewer vulnerabilities than TLS 1.2 or below. This 163 document is being republished with this in mind, and with an explicit 164 goal to migrate most uses of TLS 1.2 into TLS 1.3. 166 These are minimum recommendations for the use of TLS in the vast 167 majority of implementation and deployment scenarios, with the 168 exception of unauthenticated TLS (see Section 5). Other 169 specifications that reference this document can have stricter 170 requirements related to one or more aspects of the protocol, based on 171 their particular circumstances (e.g., for use with a particular 172 application protocol); when that is the case, implementers are 173 advised to adhere to those stricter requirements. Furthermore, this 174 document provides a floor, not a ceiling, so stronger options are 175 always allowed (e.g., depending on differing evaluations of the 176 importance of cryptographic strength vs. computational load). 178 Community knowledge about the strength of various algorithms and 179 feasible attacks can change quickly, and experience shows that a Best 180 Current Practice (BCP) document about security is a point-in-time 181 statement. Readers are advised to seek out any errata or updates 182 that apply to this document. 184 2. Terminology 186 A number of security-related terms in this document are used in the 187 sense defined in [RFC4949]. 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 3. General Recommendations 197 This section provides general recommendations on the secure use of 198 TLS. Recommendations related to cipher suites are discussed in the 199 following section. 201 3.1. Protocol Versions 203 3.1.1. SSL/TLS Protocol Versions 205 It is important both to stop using old, less secure versions of SSL/ 206 TLS and to start using modern, more secure versions; therefore, the 207 following are the recommendations concerning TLS/SSL protocol 208 versions: 210 * Implementations MUST NOT negotiate SSL version 2. 212 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 214 * Implementations MUST NOT negotiate SSL version 3. 216 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 217 plugged some significant security holes but did not support strong 218 cipher suites. SSLv3 does not support TLS extensions, some of 219 which (e.g., renegotiation_info [RFC5746]) are security-critical. 220 In addition, with the emergence of the POODLE attack [POODLE], 221 SSLv3 is now widely recognized as fundamentally insecure. See 222 [DEP-SSLv3] for further details. 224 * Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 226 Rationale: TLS 1.0 (published in 1999) does not support many 227 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 228 record Initialization Vector (IV) for CBC-based cipher suites and 229 does not warn against common padding errors. This and other 230 recommendations in this section are in line with [RFC8996]. 232 * Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 234 Rationale: TLS 1.1 (published in 2006) is a security improvement 235 over TLS 1.0 but still does not support certain stronger cipher 236 suites. 238 NOTE: This recommendation has been changed from SHOULD NOT to MUST 239 NOT on the assumption that [I-D.ietf-tls-oldversions-deprecate] 240 will be published as an RFC before this document. 242 * Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to 243 negotiate TLS version 1.2 over earlier versions of TLS. 245 Rationale: Several stronger cipher suites are available only with 246 TLS 1.2 (published in 2008). In fact, the cipher suites 247 recommended by this document for TLS 1.2 (Section 4.2 below) are 248 only available in this version. 250 * Implementations SHOULD support TLS 1.3 [RFC8446] and if 251 implemented, MUST prefer to negotiate TLS 1.3 over earlier 252 versions of TLS. 254 Rationale: TLS 1.3 is a major overhaul to the protocol and 255 resolves many of the security issues with TLS 1.2. We note that 256 as long as TLS 1.2 is still allowed by a particular 257 implementation, even if it defaults to TLS 1.3, implementers MUST 258 still follow all the recommendations in this document. 260 * Implementations of "greenfield" protocols or deployments, where 261 there is no need to support legacy endpoints, SHOULD support TLS 262 1.3, with no negotiation of earlier versions. Similarly, we 263 RECOMMEND that new protocol designs that embed the TLS mechanisms 264 (such as QUIC has done [RFC9001]) include TLS 1.3. 266 Rationale: secure deployment of TLS 1.3 is significantly easier 267 and less error prone than the secure deployment of TLS 1.2. 269 This BCP applies to TLS 1.2, 1.3 and to earlier versions. It is not 270 safe for readers to assume that the recommendations in this BCP apply 271 to any future version of TLS. 273 3.1.2. DTLS Protocol Versions 275 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 276 1.1 was published. The following are the recommendations with 277 respect to DTLS: 279 * Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347]. 281 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 283 * Implementations MUST support and (unless a higher version is 284 available) MUST prefer to negotiate DTLS version 1.2 [RFC6347] 286 Version 1.2 of DTLS correlates to version 1.2 of TLS (see above). 287 (There is no version 1.1 of DTLS.) 289 * Implementations SHOULD support and, if available, MUST prefer to 290 negotiate DTLS version 1.3 as specified in [I-D.ietf-tls-dtls13]. 292 Version 1.3 of DTLS correlates to version 1.3 of TLS (see above). 294 3.1.3. Fallback to Lower Versions 296 Clients that "fall back" to lower versions of the protocol after the 297 server rejects higher versions of the protocol MUST NOT fall back to 298 SSLv3 or earlier. Implementations of TLS/DTLS 1.2 or earlier MUST 299 implement the Fallback SCSV mechanism [RFC7507] to prevent such 300 fallback being forced by an attacker. 302 Rationale: Some client implementations revert to lower versions of 303 TLS or even to SSLv3 if the server rejected higher versions of the 304 protocol. This fallback can be forced by a man-in-the-middle (MITM) 305 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 306 1.2 but at least TLS 1.0 is still allowed by many web servers. As of 307 this writing, the Fallback SCSV solution is widely deployed and 308 proven as a robust solution to this problem. 310 3.2. Strict TLS 312 The following recommendations are provided to help prevent SSL 313 Stripping (an attack that is summarized in Section 2.1 of [RFC7457]): 315 * In cases where an application protocol allows implementations or 316 deployments a choice between strict TLS configuration and dynamic 317 upgrade from unencrypted to TLS-protected traffic (such as 318 STARTTLS), clients and servers SHOULD prefer strict TLS 319 configuration. 321 * Application protocols typically provide a way for the server to 322 offer TLS during an initial protocol exchange, and sometimes also 323 provide a way for the server to advertise support for TLS (e.g., 324 through a flag indicating that TLS is required); unfortunately, 325 these indications are sent before the communication channel is 326 encrypted. A client SHOULD attempt to negotiate TLS even if these 327 indications are not communicated by the server. 329 * HTTP client and server implementations MUST support the HTTP 330 Strict Transport Security (HSTS) header [RFC6797], in order to 331 allow Web servers to advertise that they are willing to accept 332 TLS-only clients. 334 * Web servers SHOULD use HSTS to indicate that they are willing to 335 accept TLS-only clients, unless they are deployed in such a way 336 that using HSTS would in fact weaken overall security (e.g., it 337 can be problematic to use HSTS with self-signed certificates, as 338 described in Section 11.3 of [RFC6797]). 340 Rationale: Combining unprotected and TLS-protected communication 341 opens the way to SSL Stripping and similar attacks, since an initial 342 part of the communication is not integrity protected and therefore 343 can be manipulated by an attacker whose goal is to keep the 344 communication in the clear. 346 3.3. Compression 348 In order to help prevent compression-related attacks (summarized in 349 Section 2.6 of [RFC7457]), when using TLS 1.2 implementations and 350 deployments SHOULD disable TLS-level compression (Section 6.2.2 of 351 [RFC5246]), unless the application protocol in question has been 352 shown not to be open to such attacks. Note: this recommendation 353 applies to TLS 1.2 only, because compression has been removed from 354 TLS 1.3. 356 Rationale: TLS compression has been subject to security attacks, such 357 as the CRIME attack. 359 Implementers should note that compression at higher protocol levels 360 can allow an active attacker to extract cleartext information from 361 the connection. The BREACH attack is one such case. These issues 362 can only be mitigated outside of TLS and are thus outside the scope 363 of this document. See Section 2.6 of [RFC7457] for further details. 365 3.4. TLS Session Resumption 367 Session resumption drastically reduces the number of TLS handshakes 368 and thus is an essential performance feature for most deployments. 370 Stateless session resumption with session tickets is a popular 371 strategy. For TLS 1.2, it is specified in [RFC5077]. For TLS 1.3, 372 an equivalent PSK-based mechanism is described in Section 4.6.1 of 373 [RFC8446]. When it is used, the resumption information MUST be 374 authenticated and encrypted to prevent modification or eavesdropping 375 by an attacker. Further recommendations apply to session tickets: 377 * A strong cipher suite MUST be used when encrypting the ticket (as 378 least as strong as the main TLS cipher suite). 380 * Ticket keys MUST be changed regularly, e.g., once every week, so 381 as not to negate the benefits of forward secrecy (see Section 6.3 382 for details on forward secrecy). 384 * For similar reasons, session ticket validity SHOULD be limited to 385 a reasonable duration (e.g., half as long as ticket key validity). 387 Rationale: session resumption is another kind of TLS handshake, and 388 therefore must be as secure as the initial handshake. This document 389 (Section 4) recommends the use of cipher suites that provide forward 390 secrecy, i.e. that prevent an attacker who gains momentary access to 391 the TLS endpoint (either client or server) and its secrets from 392 reading either past or future communication. The tickets must be 393 managed so as not to negate this security property. 395 TLS 1.3 provides the powerful option of forward secrecy even within a 396 long-lived connection that is periodically resumed. Section 2.2 of 397 [RFC8446] recommends that clients SHOULD send a "key_share" when 398 initiating session resumption. In order to gain forward secrecy, 399 this document recommends that server implementations SHOULD respond 400 with a "key_share", to complete an ECDHE exchange on each session 401 resumption. 403 TLS session resumption introduces potential privacy issues where the 404 server is able to track the client, in some cases indefinitely. See 405 [Sy2018] for more details. 407 3.5. TLS Renegotiation 409 Where handshake renegotiation is implemented, both clients and 410 servers MUST implement the renegotiation_info extension, as defined 411 in [RFC5746]. Note: this recommendation applies to TLS 1.2 only, 412 because renegotiation has been removed from TLS 1.3. 414 A related attack resulting from TLS session parameters not properly 415 authenticated is Triple Handshake [triple-handshake]. To address 416 this attack, TLS 1.2 implementations SHOULD support the 417 extended_master_secret extension defined in [RFC7627]. 419 3.6. Post-Handshake Authentication 421 Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post- 422 handshake authentication and key update mechanisms. In the context 423 of protocols that multiplex requests over a single connection (such 424 as HTTP/2), post-handshake authentication has the same problems as 425 TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the 426 advice provided for HTTP/2 in [RFC8740]. 428 3.7. Server Name Indication 430 TLS implementations MUST support the Server Name Indication (SNI) 431 extension defined in Section 3 of [RFC6066] for those higher-level 432 protocols that would benefit from it, including HTTPS. However, the 433 actual use of SNI in particular circumstances is a matter of local 434 policy. Implementers are strongly encouraged to support TLS 435 Encrypted Client Hello (formerly called Encrypted SNI) once 436 [I-D.ietf-tls-esni] has been standardized. 438 Rationale: SNI supports deployment of multiple TLS-protected virtual 439 servers on a single address, and therefore enables fine-grained 440 security for these virtual servers, by allowing each one to have its 441 own certificate. However, SNI also leaks the target domain for a 442 given connection; this information leak will be plugged by use of TLS 443 Encrypted Client Hello. 445 In order to prevent the attacks described in [ALPACA], a server that 446 does not recognize the presented server name SHOULD NOT continue the 447 handshake and instead fail with a fatal-level unrecognized_name(112) 448 alert. Note that this recommendation updates Section 3 of [RFC6066]: 449 "If the server understood the ClientHello extension but does not 450 recognize the server name, the server SHOULD take one of two actions: 451 either abort the handshake by sending a fatal-level 452 unrecognized_name(112) alert or continue the handshake." It is also 453 RECOMMENDED that clients abort the handshake if the server 454 acknowledges the SNI hostname with a different hostname than the one 455 sent by the client. 457 3.8. Application-Layer Protocol Negotiation 459 TLS implementations (both client- and server-side) MUST support the 460 Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. 462 In order to prevent "cross-protocol" attacks resulting from failure 463 to ensure that a message intended for use in one protocol cannot be 464 mistaken for a message for use in another protocol, servers should 465 strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: 466 "In the event that the server supports no protocols that the client 467 advertises, then the server SHALL respond with a fatal 468 no_application_protocol alert." It is also RECOMMENDED that clients 469 abort the handshake if the server acknowledges the ALPN extension, 470 but does not select a protocol from the client list. Failure to do 471 so can result in attacks such those described in [ALPACA]. 473 Protocol developers are strongly encouraged to register an ALPN 474 identifier for their protocols. This applies to new protocols, as 475 well as well-established protocols such as SMTP. 477 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 479 The 0-RTT early data feature is new in TLS 1.3. It provides improved 480 latency when TLS connections are resumed, at the potential cost of 481 security. As a result, it requires special attention from 482 implementers on both the server and the client side. Typically this 483 extends to both the TLS library as well as protocol layers above it. 485 For use in HTTP-over-TLS, readers are referred to [RFC8470] for 486 guidance. 488 For QUIC-on-TLS, refer to Sec. 9.2 of [RFC9001]. 490 For other protocols, generic guidance is given in Sec. 8 and 491 Appendix E.5 of [RFC8446]. Given the complexity, we RECOMMEND to 492 avoid this feature altogether unless an explicit specification exists 493 for the application protocol in question to clarify when 0-RTT is 494 appropriate and secure. This can take the form of an IETF RFC, a 495 non-IETF standard, or even documentation associated with a non- 496 standard protocol. 498 4. Recommendations: Cipher Suites 500 TLS and its implementations provide considerable flexibility in the 501 selection of cipher suites. Unfortunately, some available cipher 502 suites are insecure, some do not provide the targeted security 503 services, and some no longer provide enough security. Incorrectly 504 configuring a server leads to no or reduced security. This section 505 includes recommendations on the selection and negotiation of cipher 506 suites. 508 4.1. General Guidelines 510 Cryptographic algorithms weaken over time as cryptanalysis improves: 511 algorithms that were once considered strong become weak. Such 512 algorithms need to be phased out over time and replaced with more 513 secure cipher suites. This helps to ensure that the desired security 514 properties still hold. SSL/TLS has been in existence for almost 20 515 years and many of the cipher suites that have been recommended in 516 various versions of SSL/TLS are now considered weak or at least not 517 as strong as desired. Therefore, this section modernizes the 518 recommendations concerning cipher suite selection. 520 * Implementations MUST NOT negotiate the cipher suites with NULL 521 encryption. 523 Rationale: The NULL cipher suites do not encrypt traffic and so 524 provide no confidentiality services. Any entity in the network 525 with access to the connection can view the plaintext of contents 526 being exchanged by the client and server. 527 Nevertheless, this document does not discourage software from 528 implementing NULL cipher suites, since they can be useful for 529 testing and debugging. 531 * Implementations MUST NOT negotiate RC4 cipher suites. 533 Rationale: The RC4 stream cipher has a variety of cryptographic 534 weaknesses, as documented in [RFC7465]. Note that DTLS 535 specifically forbids the use of RC4 already. 537 * Implementations MUST NOT negotiate cipher suites offering less 538 than 112 bits of security, including so-called "export-level" 539 encryption (which provide 40 or 56 bits of security). 541 Rationale: Based on [RFC3766], at least 112 bits of security is 542 needed. 40-bit and 56-bit security are considered insecure today. 543 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. 545 * Implementations SHOULD NOT negotiate cipher suites that use 546 algorithms offering less than 128 bits of security. 548 Rationale: Cipher suites that offer between 112-bits and 128-bits 549 of security are not considered weak at this time; however, it is 550 expected that their useful lifespan is short enough to justify 551 supporting stronger cipher suites at this time. 128-bit ciphers 552 are expected to remain secure for at least several years, and 553 256-bit ciphers until the next fundamental technology 554 breakthrough. Note that, because of so-called "meet-in-the- 555 middle" attacks [Multiple-Encryption], some legacy cipher suites 556 (e.g., 168-bit 3DES) have an effective key length that is smaller 557 than their nominal key length (112 bits in the case of 3DES). 558 Such cipher suites should be evaluated according to their 559 effective key length. 561 * Implementations SHOULD NOT negotiate cipher suites based on RSA 562 key transport, a.k.a. "static RSA". 564 Rationale: These cipher suites, which have assigned values 565 starting with the string "TLS_RSA_WITH_*", have several drawbacks, 566 especially the fact that they do not support forward secrecy. 568 * Implementations MUST support and prefer to negotiate cipher suites 569 offering forward secrecy, such as those in the Ephemeral Diffie- 570 Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and 571 "ECDHE") families. 573 Rationale: Forward secrecy (sometimes called "perfect forward 574 secrecy") prevents the recovery of information that was encrypted 575 with older session keys, thus limiting the amount of time during 576 which attacks can be successful. See Section 6.3 for a detailed 577 discussion. 579 4.2. Recommended Cipher Suites 581 Given the foregoing considerations, implementation and deployment of 582 the following cipher suites is RECOMMENDED: 584 * TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 586 * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 588 * TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 590 * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 592 These cipher suites are supported only in TLS 1.2 and not in earlier 593 protocol versions, because they are authenticated encryption (AEAD) 594 algorithms [RFC5116]. 596 Typically, in order to prefer these suites, the order of suites needs 597 to be explicitly configured in server software. (See [BETTERCRYPTO] 598 for helpful deployment guidelines, but note that its recommendations 599 differ from the current document in some details.) It would be ideal 600 if server software implementations were to prefer these suites by 601 default. 603 Some devices have hardware support for AES-CCM but not AES-GCM, so 604 they are unable to follow the foregoing recommendations regarding 605 cipher suites. There are even devices that do not support public key 606 cryptography at all, but they are out of scope entirely. 608 4.2.1. Implementation Details 610 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 611 first proposal to any server, unless they have prior knowledge that 612 the server cannot respond to a TLS 1.2 client_hello message. 614 Servers MUST prefer this cipher suite over weaker cipher suites 615 whenever it is proposed, even if it is not the first proposal. 617 Clients are of course free to offer stronger cipher suites, e.g., 618 using AES-256; when they do, the server SHOULD prefer the stronger 619 cipher suite unless there are compelling reasons (e.g., seriously 620 degraded performance) to choose otherwise. 622 This document does not change the mandatory-to-implement TLS cipher 623 suite(s) prescribed by TLS. To maximize interoperability, RFC 5246 624 mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher 625 suite, which is significantly weaker than the cipher suites 626 recommended here. (The GCM mode does not suffer from the same 627 weakness, caused by the order of MAC-then-Encrypt in TLS 628 [Krawczyk2001], since it uses an AEAD mode of operation.) 629 Implementers should consider the interoperability gain against the 630 loss in security when deploying the TLS_RSA_WITH_AES_128_CBC_SHA 631 cipher suite. Other application protocols specify other cipher 632 suites as mandatory to implement (MTI). 634 Note that some profiles of TLS 1.2 use different cipher suites. For 635 example, [RFC6460] defines a profile that uses the 636 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 637 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 639 [RFC4492] allows clients and servers to negotiate ECDH parameters 640 (curves). Both clients and servers SHOULD include the "Supported 641 Elliptic Curves" extension [RFC4492]. For interoperability, clients 642 and servers SHOULD support the NIST P-256 (secp256r1) curve 643 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 644 extension with a single element, "uncompressed". 646 4.3. Cipher Suites for TLS 1.3 648 This document does not specify any cipher suites for TLS 1.3. 649 Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite 650 recommendations. 652 4.4. Limits on Key Usage 654 All ciphers have an upper limit on the amount of traffic that can be 655 securely protected with any given key. In the case of AEAD cipher 656 suites, two separate limits are maintained for each key: 658 1. Confidentiality limit (CL), i.e., the number of records that can 659 be encrypted. 661 2. Integrity limit (IL), i.e., the number of records that are 662 allowed to fail authentication. 664 The latter only applies to DTLS since TLS connections are torn down 665 on the first decryption failure. 667 When a sender is approaching CL, the implementation SHOULD initiate a 668 new handshake (or in TLS 1.3, a Key Update) to rotate the session 669 key. 671 When a receiver has reached IL, the implementation SHOULD close the 672 connection. 674 For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of 675 [RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher 676 suites, readers are referred to Section 4.5.3 of 677 [I-D.ietf-tls-dtls13]. 679 For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in 680 this document, CL can be derived by plugging the corresponding 681 parameters into the inequalities in Section 6.1 of 682 [I-D.irtf-cfrg-aead-limits] that apply to random, partially implicit 683 nonces, i.e., the nonce construction used in TLS 1.2. Although the 684 obtained figures are slightly higher than those for TLS 1.3, it is 685 RECOMMENDED that the same limit of 2^24.5 records is used for both 686 versions. 688 For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained 689 from the same inequalities referenced above) is 2^28. 691 4.5. Public Key Length 693 When using the cipher suites recommended in this document, two public 694 keys are normally used in the TLS handshake: one for the Diffie- 695 Hellman key agreement and one for server authentication. Where a 696 client certificate is used, a third public key is added. 698 With a key exchange based on modular exponential (MODP) Diffie- 699 Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 700 bits are REQUIRED. 702 Rationale: For various reasons, in practice, DH keys are typically 703 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 704 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 705 would be roughly equivalent to only an 80-bit symmetric key 706 [RFC3766], it is better to use keys longer than that for the "DHE" 707 family of cipher suites. A DH key of 1926 bits would be roughly 708 equivalent to a 100-bit symmetric key [RFC3766]. A DH key of 2048 709 bits (equivalent to a 112-bit symmetric key) is the minimum allowed 710 by the latest revision of [NIST.SP.800-56A], as of this writing (see 711 in particular Appendix D). 713 As noted in [RFC3766], correcting for the emergence of a TWIRL 714 machine would imply that 1024-bit DH keys yield about 65 bits of 715 equivalent strength and that a 2048-bit DH key would yield about 92 716 bits of equivalent strength. The Logjam attack [Logjam] further 717 demonstrates that 1024-bit Diffie Hellman parameters should be 718 avoided. 720 With regard to ECDH keys, implementers are referred to the IANA 721 "Supported Groups Registry" (former "EC Named Curve Registry"), 722 within the "Transport Layer Security (TLS) Parameters" registry 723 [IANA_TLS], and in particular to the "recommended" groups. Curves of 724 less than 224 bits MUST NOT be used. This recommendation is in-line 725 with the latest revision of [NIST.SP.800-56A]. 727 When using RSA, servers SHOULD authenticate using certificates with 728 at least a 2048-bit modulus for the public key. In addition, the use 729 of the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST 730 NOT be used (see [CAB-Baseline] for more details). Clients MUST 731 indicate to servers that they request SHA-256, by using the 732 "Signature Algorithms" extension defined in TLS 1.2. 734 4.6. Truncated HMAC 736 Implementations MUST NOT use the Truncated HMAC extension, defined in 737 Section 7 of [RFC6066]. 739 Rationale: the extension does not apply to the AEAD cipher suites 740 recommended above. However it does apply to most other TLS cipher 741 suites. Its use has been shown to be insecure in [PatersonRS11]. 743 5. Applicability Statement 745 The recommendations of this document primarily apply to the 746 implementation and deployment of application protocols that are most 747 commonly used with TLS and DTLS on the Internet today. Examples 748 include, but are not limited to: 750 * Web software and services that wish to protect HTTP traffic with 751 TLS. 753 * Email software and services that wish to protect IMAP, POP3, or 754 SMTP traffic with TLS. 756 * Instant-messaging software and services that wish to protect 757 Extensible Messaging and Presence Protocol (XMPP) or Internet 758 Relay Chat (IRC) traffic with TLS. 760 * Realtime media software and services that wish to protect Secure 761 Realtime Transport Protocol (SRTP) traffic with DTLS. 763 This document does not modify the implementation and deployment 764 recommendations (e.g., mandatory-to-implement cipher suites) 765 prescribed by existing application protocols that employ TLS or DTLS. 766 If the community that uses such an application protocol wishes to 767 modernize its usage of TLS or DTLS to be consistent with the best 768 practices recommended here, it needs to explicitly update the 769 existing application protocol definition (one example is [TLS-XMPP], 770 which updates [RFC6120]). 772 Designers of new application protocols developed through the Internet 773 Standards Process [RFC2026] are expected at minimum to conform to the 774 best practices recommended here, unless they provide documentation of 775 compelling reasons that would prevent such conformance (e.g., 776 widespread deployment on constrained devices that lack support for 777 the necessary algorithms). 779 5.1. Security Services 781 This document provides recommendations for an audience that wishes to 782 secure their communication with TLS to achieve the following: 784 * Confidentiality: all application-layer communication is encrypted 785 with the goal that no party should be able to decrypt it except 786 the intended receiver. 788 * Data integrity: any changes made to the communication in transit 789 are detectable by the receiver. 791 * Authentication: an endpoint of the TLS communication is 792 authenticated as the intended entity to communicate with. 794 With regard to authentication, TLS enables authentication of one or 795 both endpoints in the communication. In the context of opportunistic 796 security [RFC7435], TLS is sometimes used without authentication. As 797 discussed in Section 5.2, considerations for opportunistic security 798 are not in scope for this document. 800 If deployers deviate from the recommendations given in this document, 801 they need to be aware that they might lose access to one of the 802 foregoing security services. 804 This document applies only to environments where confidentiality is 805 required. It recommends algorithms and configuration options that 806 enforce secrecy of the data in transit. 808 This document also assumes that data integrity protection is always 809 one of the goals of a deployment. In cases where integrity is not 810 required, it does not make sense to employ TLS in the first place. 811 There are attacks against confidentiality-only protection that 812 utilize the lack of integrity to also break confidentiality (see, for 813 instance, [DegabrieleP07] in the context of IPsec). 815 This document addresses itself to application protocols that are most 816 commonly used on the Internet with TLS and DTLS. Typically, all 817 communication between TLS clients and TLS servers requires all three 818 of the above security services. This is particularly true where TLS 819 clients are user agents like Web browsers or email software. 821 This document does not address the rarer deployment scenarios where 822 one of the above three properties is not desired, such as the use 823 case described in Section 5.2 below. As another scenario where 824 confidentiality is not needed, consider a monitored network where the 825 authorities in charge of the respective traffic domain require full 826 access to unencrypted (plaintext) traffic, and where users 827 collaborate and send their traffic in the clear. 829 5.2. Opportunistic Security 831 There are several important scenarios in which the use of TLS is 832 optional, i.e., the client decides dynamically ("opportunistically") 833 whether to use TLS with a particular server or to connect in the 834 clear. This practice, often called "opportunistic security", is 835 described at length in [RFC7435] and is often motivated by a desire 836 for backward compatibility with legacy deployments. 838 In these scenarios, some of the recommendations in this document 839 might be too strict, since adhering to them could cause fallback to 840 cleartext, a worse outcome than using TLS with an outdated protocol 841 version or cipher suite. 843 6. Security Considerations 845 This entire document discusses the security practices directly 846 affecting applications using the TLS protocol. This section contains 847 broader security considerations related to technologies used in 848 conjunction with or by TLS. 850 6.1. Host Name Validation 852 Application authors should take note that some TLS implementations do 853 not validate host names. If the TLS implementation they are using 854 does not validate host names, authors might need to write their own 855 validation code or consider using a different TLS implementation. 857 It is noted that the requirements regarding host name validation 858 (and, in general, binding between the TLS layer and the protocol that 859 runs above it) vary between different protocols. For HTTPS, these 860 requirements are defined by Sections 4.3.3, 4.3.4 and 4.3.5 of 861 [I-D.ietf-httpbis-semantics]. 863 Readers are referred to [RFC6125] for further details regarding 864 generic host name validation in the TLS context. In addition, that 865 RFC contains a long list of example protocols, some of which 866 implement a policy very different from HTTPS. 868 If the host name is discovered indirectly and in an insecure manner 869 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 870 NOT be used as a reference identifier [RFC6125] even when it matches 871 the presented certificate. This proviso does not apply if the host 872 name is discovered securely (for further discussion, see [DANE-SRV] 873 and [DANE-SMTP]). 875 Host name validation typically applies only to the leaf "end entity" 876 certificate. Naturally, in order to ensure proper authentication in 877 the context of the PKI, application clients need to verify the entire 878 certification path in accordance with [RFC5280] (see also [RFC6125]). 880 6.2. AES-GCM 882 Section 4.2 above recommends the use of the AES-GCM authenticated 883 encryption algorithm. Please refer to Section 11 of [RFC5246] for 884 general security considerations when using TLS 1.2, and to Section 6 885 of [RFC5288] for security considerations that apply specifically to 886 AES-GCM when used with TLS. 888 6.2.1. Nonce Reuse in TLS 1.2 890 The existence of deployed TLS stacks that mistakenly reuse the AES- 891 GCM nonce is documented in [Boeck2016], showing there is an actual 892 risk of AES-GCM getting implemented in an insecure way and thus 893 making TLS sessions that use an AES-GCM cipher suite vulnerable to 894 attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE- 895 2016-10213, CVE-2016-10212, CVE-2017-5933.) 897 While this problem has been fixed in TLS 1.3, which enforces a 898 deterministic method to generate nonces from record sequence numbers 899 and shared secrets for all of its AEAD cipher suites (including AES- 900 GCM), TLS 1.2 implementations could still choose their own 901 (potentially insecure) nonce generation methods. 903 It is therefore RECOMMENDED that TLS 1.2 implementations use the 904 64-bit sequence number to populate the nonce_explicit part of the GCM 905 nonce, as described in the first two paragraphs of Section 5.3 of 906 [RFC8446]. Note that this recommendation updates Section 3 of 907 [RFC5288]: "The nonce_explicit MAY be the 64-bit sequence number." 909 We note that at the time of writing there are no cipher suites 910 defined for nonce reuse resistant algorithms such as AES-GCM-SIV 911 [RFC8452]. 913 6.3. Forward Secrecy 915 Forward secrecy (also called "perfect forward secrecy" or "PFS" and 916 defined in [RFC4949]) is a defense against an attacker who records 917 encrypted conversations where the session keys are only encrypted 918 with the communicating parties' long-term keys. 920 Should the attacker be able to obtain these long-term keys at some 921 point later in time, the session keys and thus the entire 922 conversation could be decrypted. 924 In the context of TLS and DTLS, such compromise of long-term keys is 925 not entirely implausible. It can happen, for example, due to: 927 * A client or server being attacked by some other attack vector, and 928 the private key retrieved. 930 * A long-term key retrieved from a device that has been sold or 931 otherwise decommissioned without prior wiping. 933 * A long-term key used on a device as a default key [Heninger2012]. 935 * A key generated by a trusted third party like a CA, and later 936 retrieved from it either by extortion or compromise 937 [Soghoian2011]. 939 * A cryptographic break-through, or the use of asymmetric keys with 940 insufficient length [Kleinjung2010]. 942 * Social engineering attacks against system administrators. 944 * Collection of private keys from inadequately protected backups. 946 Forward secrecy ensures in such cases that it is not feasible for an 947 attacker to determine the session keys even if the attacker has 948 obtained the long-term keys some time after the conversation. It 949 also protects against an attacker who is in possession of the long- 950 term keys but remains passive during the conversation. 952 Forward secrecy is generally achieved by using the Diffie-Hellman 953 scheme to derive session keys. The Diffie-Hellman scheme has both 954 parties maintain private secrets and send parameters over the network 955 as modular powers over certain cyclic groups. The properties of the 956 so-called Discrete Logarithm Problem (DLP) allow the parties to 957 derive the session keys without an eavesdropper being able to do so. 958 There is currently no known attack against DLP if sufficiently large 959 parameters are chosen. A variant of the Diffie-Hellman scheme uses 960 Elliptic Curves instead of the originally proposed modular 961 arithmetic. 963 Unfortunately, many TLS/DTLS cipher suites were defined that do not 964 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This 965 document therefore advocates strict use of forward-secrecy-only 966 ciphers. 968 6.4. Diffie-Hellman Exponent Reuse 970 For performance reasons, many TLS implementations reuse Diffie- 971 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 972 connections. Such reuse can result in major security issues: 974 * If exponents are reused for too long (e.g., even more than a few 975 hours), an attacker who gains access to the host can decrypt 976 previous connections. In other words, exponent reuse negates the 977 effects of forward secrecy. 979 * TLS implementations that reuse exponents should test the DH public 980 key they receive for group membership, in order to avoid some 981 known attacks. These tests are not standardized in TLS at the 982 time of writing. See [RFC6989] for recipient tests required of 983 IKEv2 implementations that reuse DH exponents. 985 * Under certain conditions, the use of static DH keys, or of 986 ephemeral DH keys that are reused across multiple connections, can 987 lead to timing attacks (such as those described in [RACCOON]) on 988 the shared secrets used in Diffie-Hellman key exchange. 990 To address these concerns, TLS implementations SHOULD NOT use static 991 DH keys and SHOULD NOT reuse ephemeral DH keys across multiple 992 connections. 994 // TODO: revisit when draft-bartle-tls-deprecate-ffdhe becomes a TLS 995 // WG item, since it specifies MUST NOT rather than SHOULD NOT. 997 6.5. Certificate Revocation 999 The following considerations and recommendations represent the 1000 current state of the art regarding certificate revocation, even 1001 though no complete and efficient solution exists for the problem of 1002 checking the revocation status of common public key certificates 1003 [RFC5280]: 1005 * Although Certificate Revocation Lists (CRLs) are the most widely 1006 supported mechanism for distributing revocation information, they 1007 have known scaling challenges that limit their usefulness (despite 1008 workarounds such as partitioned CRLs and delta CRLs). 1010 * Proprietary mechanisms that embed revocation lists in the Web 1011 browser's configuration database cannot scale beyond a small 1012 number of the most heavily used Web servers. 1014 * The On-Line Certification Status Protocol (OCSP) [RFC6960] 1015 presents both scaling and privacy issues. In addition, clients 1016 typically "soft-fail", meaning that they do not abort the TLS 1017 connection if the OCSP server does not respond. (However, this 1018 might be a workaround to avoid denial-of-service attacks if an 1019 OCSP responder is taken offline.) 1021 * The TLS Certificate Status Request extension (Section 8 of 1022 [RFC6066]), commonly called "OCSP stapling", resolves the 1023 operational issues with OCSP. However, it is still ineffective in 1024 the presence of a MITM attacker because the attacker can simply 1025 ignore the client's request for a stapled OCSP response. 1027 * OCSP stapling as defined in [RFC6066] does not extend to 1028 intermediate certificates used in a certificate chain. Although 1029 the Multiple Certificate Status extension [RFC6961] addresses this 1030 shortcoming, it is a recent addition without much deployment. 1032 * Both CRLs and OCSP depend on relatively reliable connectivity to 1033 the Internet, which might not be available to certain kinds of 1034 nodes (such as newly provisioned devices that need to establish a 1035 secure connection in order to boot up for the first time). 1037 With regard to common public key certificates, servers SHOULD support 1038 the following as a best practice given the current state of the art 1039 and as a foundation for a possible future solution: 1041 1. OCSP [RFC6960] 1042 2. Both the status_request extension defined in [RFC6066] and the 1043 status_request_v2 extension defined in [RFC6961] (This might 1044 enable interoperability with the widest range of clients.) 1046 3. The OCSP stapling extension defined in [RFC6961] 1048 The considerations in this section do not apply to scenarios where 1049 the DANE-TLSA resource record [RFC6698] is used to signal to a client 1050 which certificate a server considers valid and good to use for TLS 1051 connections. 1053 7. Acknowledgments 1055 The following acknowledgments are inherited from [RFC7525]. 1057 Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen 1058 Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson 1059 Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, 1060 Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom 1061 Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean 1062 Turner, and Aaron Zauner for their feedback and suggested 1063 improvements. Thanks also to Brian Smith, who has provided a great 1064 resource in his "Proposal to Change the Default TLS Ciphersuites 1065 Offered by Browsers" [Smith2013]. Finally, thanks to all others who 1066 commented on the TLS, UTA, and other discussion lists but who are not 1067 mentioned here by name. 1069 Robert Sparks and Dave Waltermire provided helpful reviews on behalf 1070 of the General Area Review Team and the Security Directorate, 1071 respectively. 1073 During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins, 1074 Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick 1075 provided comments that led to further improvements. 1077 Ralph Holz gratefully acknowledges the support by Technische 1078 Universitaet Muenchen. 1080 The authors gratefully acknowledge the assistance of Leif Johansson 1081 and Orit Levin as the working group chairs and Pete Resnick as the 1082 sponsoring Area Director. 1084 8. References 1086 8.1. Normative References 1088 [I-D.ietf-httpbis-semantics] 1089 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1090 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1091 httpbis-semantics-19, 12 September 2021, 1092 . 1095 [I-D.ietf-tls-dtls13] 1096 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1097 Datagram Transport Layer Security (DTLS) Protocol Version 1098 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1099 dtls13-43, 30 April 2021, 1100 . 1103 [I-D.ietf-tls-oldversions-deprecate] 1104 Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1105 1.1", Work in Progress, Internet-Draft, draft-ietf-tls- 1106 oldversions-deprecate-12, 21 January 2021, 1107 . 1110 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1111 Requirement Levels", BCP 14, RFC 2119, 1112 DOI 10.17487/RFC2119, March 1997, 1113 . 1115 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1116 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1117 RFC 3766, DOI 10.17487/RFC3766, April 2004, 1118 . 1120 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1121 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1122 for Transport Layer Security (TLS)", RFC 4492, 1123 DOI 10.17487/RFC4492, May 2006, 1124 . 1126 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1127 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1128 . 1130 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1131 (TLS) Protocol Version 1.2", RFC 5246, 1132 DOI 10.17487/RFC5246, August 2008, 1133 . 1135 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1136 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1137 DOI 10.17487/RFC5288, August 2008, 1138 . 1140 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1141 "Transport Layer Security (TLS) Renegotiation Indication 1142 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 1143 . 1145 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1146 Extensions: Extension Definitions", RFC 6066, 1147 DOI 10.17487/RFC6066, January 2011, 1148 . 1150 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1151 Verification of Domain-Based Application Service Identity 1152 within Internet Public Key Infrastructure Using X.509 1153 (PKIX) Certificates in the Context of Transport Layer 1154 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1155 2011, . 1157 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 1158 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 1159 2011, . 1161 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1162 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1163 January 2012, . 1165 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1166 "Transport Layer Security (TLS) Application-Layer Protocol 1167 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1168 July 2014, . 1170 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 1171 DOI 10.17487/RFC7465, February 2015, 1172 . 1174 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1175 Suite Value (SCSV) for Preventing Protocol Downgrade 1176 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 1177 . 1179 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1180 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1181 Session Hash and Extended Master Secret Extension", 1182 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1183 . 1185 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1186 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1187 May 2017, . 1189 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1190 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1191 . 1193 [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, 1194 DOI 10.17487/RFC8740, February 2020, 1195 . 1197 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1198 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1199 . 1201 8.2. Informative References 1203 [ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D., 1204 Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel, 1205 "ALPACA: Application Layer Protocol Confusion - Analyzing 1206 and Mitigating Cracks in TLS Authentication", 30th USENIX 1207 Security Symposium (USENIX Security 21) , 2021, 1208 . 1211 [BETTERCRYPTO] 1212 bettercrypto.org, "Applied Crypto Hardening", April 2015, 1213 . 1215 [Boeck2016] 1216 Böck, H., Zauner, A., Devlin, S., Somorovsky, J., and P. 1217 Jovanovic, "Nonce-Disrespecting Adversaries: Practical 1218 Forgery Attacks on GCM in TLS", May 2016, 1219 . 1221 [CAB-Baseline] 1222 CA/Browser Forum, "Baseline Requirements for the Issuance 1223 and Management of Publicly-Trusted Certificates Version 1224 1.1.6", 2013, . 1226 [CVE] MITRE, "Common Vulnerabilities and Exposures", 1227 . 1229 [DANE-SMTP] 1230 Dukhovni, V. and W. Hardaker, "SMTP Security via 1231 Opportunistic DNS-Based Authentication of Named Entities 1232 (DANE) Transport Layer Security (TLS)", RFC 7672, 1233 DOI 10.17487/RFC7672, October 2015, 1234 . 1236 [DANE-SRV] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1237 Based Authentication of Named Entities (DANE) TLSA Records 1238 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 1239 2015, . 1241 [DegabrieleP07] 1242 Degabriele, J. and K. Paterson, "Attacking the IPsec 1243 Standards in Encryption-only Configurations", 2007 IEEE 1244 Symposium on Security and Privacy (SP '07), 1245 DOI 10.1109/sp.2007.8, May 2007, 1246 . 1248 [DEP-SSLv3] 1249 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1250 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 1251 DOI 10.17487/RFC7568, June 2015, 1252 . 1254 [Heninger2012] 1255 Heninger, N., Durumeric, Z., Wustrow, E., and J.A. 1256 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1257 Weak Keys in Network Devices", Usenix Security 1258 Symposium 2012, 2012. 1260 [I-D.ietf-tls-esni] 1261 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1262 Encrypted Client Hello", Work in Progress, Internet-Draft, 1263 draft-ietf-tls-esni-13, 12 August 2021, 1264 . 1267 [I-D.irtf-cfrg-aead-limits] 1268 Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on 1269 AEAD Algorithms", Work in Progress, Internet-Draft, draft- 1270 irtf-cfrg-aead-limits-03, 12 July 2021, 1271 . 1274 [IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters", 1275 . 1277 [Joux2006] Joux, A., "Authentication Failures in NIST version of 1278 GCM", 2006, . 1282 [Kleinjung2010] 1283 Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thomé, 1284 E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P., 1285 Osvik, D., te Riele, H., Timofeev, A., and P. Zimmermann, 1286 "Factorization of a 768-Bit RSA Modulus", Advances in 1287 Cryptology - CRYPTO 2010 pp. 333-350, 1288 DOI 10.1007/978-3-642-14623-7_18, 2010, 1289 . 1291 [Krawczyk2001] 1292 Krawczyk, H., "The Order of Encryption and Authentication 1293 for Protecting Communications (Or: How Secure is SSL?)", 1294 CRYPTO 01, 2001, 1295 . 1297 [Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 1298 Green, M., Halderman, J., Heninger, N., Springall, D., 1299 Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., 1300 Zanella-Béguelin, S., and P. Zimmermann, "Imperfect 1301 Forward Secrecy: How Diffie-Hellman Fails in Practice", 1302 Proceedings of the 22nd ACM SIGSAC Conference on Computer 1303 and Communications Security, DOI 10.1145/2810103.2813707, 1304 October 2015, . 1306 [Multiple-Encryption] 1307 Merkle, R. and M. Hellman, "On the security of multiple 1308 encryption", Communications of the ACM Vol. 24, pp. 1309 465-467, DOI 10.1145/358699.358718, July 1981, 1310 . 1312 [NIST.SP.800-56A] 1313 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1314 Davis, "Recommendation for pair-wise key-establishment 1315 schemes using discrete logarithm cryptography", National 1316 Institute of Standards and Technology report, 1317 DOI 10.6028/nist.sp.800-56ar3, April 2018, 1318 . 1320 [PatersonRS11] 1321 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 1322 Does Matter: Attacks and Proofs for the TLS Record 1323 Protocol", Lecture Notes in Computer Science pp. 372-389, 1324 DOI 10.1007/978-3-642-25385-0_20, 2011, 1325 . 1327 [POODLE] US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE 1328 Attack", October 2014, 1329 . 1331 [RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J., 1332 Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and 1333 Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)", 1334 30th USENIX Security Symposium (USENIX Security 21) , 1335 2021, . 1338 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1339 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1340 . 1342 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1343 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1344 . 1346 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1347 Algorithm and Its Use with IPsec", RFC 3602, 1348 DOI 10.17487/RFC3602, September 2003, 1349 . 1351 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1352 (TLS) Protocol Version 1.1", RFC 4346, 1353 DOI 10.17487/RFC4346, April 2006, 1354 . 1356 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1357 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1358 . 1360 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1361 "Transport Layer Security (TLS) Session Resumption without 1362 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1363 January 2008, . 1365 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1366 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1367 . 1369 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1370 Housley, R., and W. Polk, "Internet X.509 Public Key 1371 Infrastructure Certificate and Certificate Revocation List 1372 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1373 . 1375 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1376 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1377 DOI 10.17487/RFC6101, August 2011, 1378 . 1380 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1381 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1382 March 2011, . 1384 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 1385 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 1386 January 2012, . 1388 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1389 of Named Entities (DANE) Transport Layer Security (TLS) 1390 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1391 2012, . 1393 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1394 Transport Security (HSTS)", RFC 6797, 1395 DOI 10.17487/RFC6797, November 2012, 1396 . 1398 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1399 Galperin, S., and C. Adams, "X.509 Internet Public Key 1400 Infrastructure Online Certificate Status Protocol - OCSP", 1401 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1402 . 1404 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1405 Multiple Certificate Status Request Extension", RFC 6961, 1406 DOI 10.17487/RFC6961, June 2013, 1407 . 1409 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 1410 Tests for the Internet Key Exchange Protocol Version 2 1411 (IKEv2)", RFC 6989, DOI 10.17487/RFC6989, July 2013, 1412 . 1414 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1415 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1416 December 2014, . 1418 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1419 Known Attacks on Transport Layer Security (TLS) and 1420 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1421 February 2015, . 1423 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1424 "Recommendations for Secure Use of Transport Layer 1425 Security (TLS) and Datagram Transport Layer Security 1426 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1427 2015, . 1429 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: 1430 Nonce Misuse-Resistant Authenticated Encryption", 1431 RFC 8452, DOI 10.17487/RFC8452, April 2019, 1432 . 1434 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1435 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1436 2018, . 1438 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1439 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1440 . 1442 [Smith2013] 1443 Smith, B., "Proposal to Change the Default TLS 1444 Ciphersuites Offered by Browsers.", 2013, 1445 . 1447 [Soghoian2011] 1448 Soghoian, C. and S. Stamm, "Certified Lies: Detecting and 1449 Defeating Government Interception Attacks Against SSL", 1450 SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010, 1451 . 1453 [Sy2018] Sy, E., Burkert, C., Federrath, H., and M. Fischer, 1454 "Tracking Users across the Web via TLS Session 1455 Resumption", Proceedings of the 34th Annual Computer 1456 Security Applications Conference, 1457 DOI 10.1145/3274694.3274708, December 2018, 1458 . 1460 [TLS-XMPP] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 1461 Security (TLS) in the Extensible Messaging and Presence 1462 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 1463 2015, . 1465 [triple-handshake] 1466 Bhargavan, K., Lavaud, A., Fournet, C., Pironti, A., and 1467 P. Strub, "Triple Handshakes and Cookie Cutters: Breaking 1468 and Fixing Authentication over TLS", 2014 IEEE Symposium 1469 on Security and Privacy, DOI 10.1109/sp.2014.14, May 2014, 1470 . 1472 Appendix A. Differences from RFC 7525 1474 This revision of the Best Current Practices contains numerous 1475 changes, and this section is focused on the normative changes. 1477 * High level differences: 1479 - Clarified items (e.g. renegotiation) that only apply to TLS 1480 1.2. 1482 - Changed status of TLS 1.0 and 1.1 from SHOULD NOT to MUST NOT. 1484 - Added TLS 1.3 at a SHOULD level. 1486 - Similar changes to DTLS, pending publication of DTLS 1.3. 1488 - Specific guidance for multiplexed protocols. 1490 - MUST-level implementation requirement for ALPN, and more 1491 specific SHOULD-level guidance for ALPN and SNI. 1493 - Limits on key usage. 1495 - New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce- 1496 Disrespecting Adversaries". 1498 * Differences specific to TLS 1.2: 1500 - Fallback SCSV as a MUST for TLS 1.2. 1502 - SHOULD-level guidance on AES-GCM nonce generation. 1504 - SHOULD NOT use static DH keys or reuse ephemeral DH keys across 1505 multiple connections. 1507 - 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192 1508 previously. 1510 - Support for extended_master_secret is a SHOULD. Also removed 1511 other, more complicated, related mitigations. 1513 * Differences specific to TLS 1.3: 1515 - New TLS 1.3 capabilities: 0-RTT. 1517 - Removed capabilities: renegotiation, compression. 1519 - Added mention of TLS Encrypted Client Hello, but no 1520 recommendation to use until it is finalized. 1522 - SHOULD-level requirement for forward secrecy in TLS 1.3 session 1523 resumption. 1525 - Generic SHOULD-level guidance to avoid 0-RTT unless it is 1526 documented for the particular protocol. 1528 Appendix B. Document History 1530 // Note to RFC Editor: please remove before publication. 1532 B.1. draft-ietf-uta-rfc7525bis-03 1534 * Cipher integrity and confidentiality limits. 1536 * Require extended_master_secret. 1538 B.2. draft-ietf-uta-rfc7525bis-02 1540 * Adjusted text about ALPN support in application protocols 1542 * Incorporated text from draft-ietf-tls-md5-sha1-deprecate 1544 B.3. draft-ietf-uta-rfc7525bis-01 1546 * Many more changes, including: 1548 - SHOULD-level requirement for forward secrecy in TLS 1.3 session 1549 resumption. 1551 - Removed TLS 1.2 capabilities: renegotiation, compression. 1553 - Specific guidance for multiplexed protocols. 1555 - MUST-level implementation requirement for ALPN, and more 1556 specific SHOULD-level guidance for ALPN and SNI. 1558 - Generic SHOULD-level guidance to avoid 0-RTT unless it is 1559 documented for the particular protocol. 1561 - SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. 1563 - SHOULD NOT use static DH keys or reuse ephemeral DH keys across 1564 multiple connections. 1566 - 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from 1567 192. 1569 B.4. draft-ietf-uta-rfc7525bis-00 1571 * Renamed: WG document. 1573 * Started populating list of changes from RFC 7525. 1575 * General rewording of abstract and intro for revised version. 1577 * Protocol versions, fallback. 1579 * Reference to ECHO. 1581 B.5. draft-sheffer-uta-rfc7525bis-00 1583 * Renamed, since the BCP number does not change. 1585 * Added an empty "Differences from RFC 7525" section. 1587 B.6. draft-sheffer-uta-bcp195bis-00 1589 * Initial release, the RFC 7525 text as-is, with some minor 1590 editorial changes to the references. 1592 Authors' Addresses 1594 Yaron Sheffer 1595 Intuit 1597 Email: yaronf.ietf@gmail.com 1599 Ralph Holz 1600 University of Twente 1602 Email: ralph.ietf@gmail.com 1604 Peter Saint-Andre 1605 Mozilla 1606 Email: stpeter@mozilla.com 1608 Thomas Fossati 1609 arm 1611 Email: thomas.fossati@arm.com