< draft-ietf-uta-rfc7525bis-04.txt   draft-ietf-uta-rfc7525bis-05.txt >
UTA Working Group Y. Sheffer UTA Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Obsoletes: 7525 (if approved) R. Holz Obsoletes: 7525 (if approved) P. Saint-Andre
Updates: 5288, 6066 (if approved) University of Twente Updates: 5288, 6066 (if approved) Mozilla
Intended status: Best Current Practice P. Saint-Andre Intended status: Best Current Practice T. Fossati
Expires: 27 May 2022 Mozilla Expires: 7 August 2022 arm
T. Fossati 3 February 2022
arm
23 November 2021
Recommendations for Secure Use of Transport Layer Security (TLS) and Recommendations for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) Datagram Transport Layer Security (DTLS)
draft-ietf-uta-rfc7525bis-04 draft-ietf-uta-rfc7525bis-05
Abstract Abstract
Transport Layer Security (TLS) and Datagram Transport Layer Security Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) are widely used to protect data exchanged over application (DTLS) are widely used to protect data exchanged over application
protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
last few years, several serious attacks on TLS have emerged, years, the industry has witnessed several serious attacks on TLS and
including attacks on its most commonly used cipher suites and their DTLS, including attacks on the most commonly used cipher suites and
modes of operation. This document provides recommendations for their modes of operation. This document provides recommendations for
improving the security of deployed services that use TLS and DTLS. improving the security of deployed services that use TLS and DTLS.
The recommendations are applicable to the majority of use cases. The recommendations are applicable to the majority of use cases.
This document was published as RFC 7525 when the industry was in the This document was published as RFC 7525 when the industry was in the
midst of its transition to TLS 1.2. Years later this transition is midst of its transition to TLS 1.2. Years later this transition is
largely complete and TLS 1.3 is widely available. Given the new largely complete and TLS 1.3 is widely available. Given the new
environment, we believe new guidance is needed. environment, updated guidance is needed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 May 2022. This Internet-Draft will expire on 7 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General Recommendations . . . . . . . . . . . . . . . . . . . 5 3. General Recommendations . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5
3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5
3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6
3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7
3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8
3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9 3.5. Renegotiation in TLS 1.2 . . . . . . . . . . . . . . . . 9
3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 9 3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 10
3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10 3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10
3.8. Application-Layer Protocol Negotiation . . . . . . . . . 10 3.8. Application-Layer Protocol Negotiation . . . . . . . . . 11
3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11
4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 11 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 12
4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 11 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 12
4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 13 4.2. Cipher Suites for TLS 1.2 . . . . . . . . . . . . . . . . 13
4.2.1. Implementation Details . . . . . . . . . . . . . . . 13 4.2.1. Implementation Details . . . . . . . . . . . . . . . 14
4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14 4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 15
4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 14 4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 15
4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15 4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 16
4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16 4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 17
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 17
5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 18
5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18 6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 19
6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19 6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 20
6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 21
6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21 6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 22
6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22 6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 23
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32 Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 34
Appendix B. Document History . . . . . . . . . . . . . . . . . . 33 Appendix B. Document History . . . . . . . . . . . . . . . . . . 35
B.1. draft-ietf-uta-rfc7525bis-04 . . . . . . . . . . . . . . 33 B.1. draft-ietf-uta-rfc7525bis-05 . . . . . . . . . . . . . . 36
B.2. draft-ietf-uta-rfc7525bis-03 . . . . . . . . . . . . . . 33 B.2. draft-ietf-uta-rfc7525bis-04 . . . . . . . . . . . . . . 36
B.3. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33 B.3. draft-ietf-uta-rfc7525bis-03 . . . . . . . . . . . . . . 36
B.4. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33 B.4. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 36
B.5. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34 B.5. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 36
B.6. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34 B.6. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 37
B.7. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34 B.7. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 B.8. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Transport Layer Security (TLS) [RFC5246] and Datagram Transport Transport Layer Security (TLS) and Datagram Transport Security Layer
Security Layer (DTLS) [RFC6347] are widely used to protect data (DTLS) are widely used to protect data exchanged over application
exchanged over application protocols such as HTTP, SMTP, IMAP, POP, protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
SIP, and XMPP. Over the years leading to 2015, several serious years leading to 2015, the industry has witnessed serious attacks on
attacks on TLS have emerged, including attacks on its most commonly TLS and DTLS, including attacks on the most commonly used cipher
used cipher suites and their modes of operation. For instance, both suites and their modes of operation. For instance, both the AES-CBC
the AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms, which [RFC3602] and RC4 [RFC7465] encryption algorithms, which together
together have been the most widely deployed ciphers, have been were once the most widely deployed ciphers, have been attacked in the
attacked in the context of TLS. A companion document [RFC7457] context of TLS. A companion document [RFC7457] provides detailed
provides detailed information about these attacks and will help the information about these attacks and will help the reader understand
reader understand the rationale behind the recommendations provided the rationale behind the recommendations provided here. That
here. document has not been updated in concert with this one; instead,
newer attacks are described in this document, as are mitigations for
those attacks.
The TLS community reacted to these attacks in two ways: The TLS community reacted to these attacks in several ways:
* Detailed guidance was published on the use of TLS 1.2 and earlier * Detailed guidance was published on the use of TLS 1.2 [RFC5246]
protocol versions. This guidance is included in the original and DTLS 1.2 [RFC6347], along with earlier protocol versions.
[RFC7525] and mostly retained in this revised version. This guidance is included in the original [RFC7525] and mostly
retained in this revised version; note that this guidance was
mostly adopted by the industry since the publication of RFC 7525
in 2015.
* A new protocol version was released, TLS 1.3 [RFC8446], which * Versions of TLS earlier than 1.2 were deprecated [RFC8996].
largely mitigates or resolves these attacks.
* Version 1.3 of TLS [RFC8446] was released and version 1.3 of DTLS
was finalized [I-D.ietf-tls-dtls13]; these versions largely
mitigate or resolve the described attacks.
Those who implement and deploy TLS and DTLS, in particular versions Those who implement and deploy TLS and DTLS, in particular versions
1.2 or earlier of these protocols, need guidance on how TLS can be 1.2 or earlier of these protocols, need guidance on how TLS can be
used securely. This document provides guidance for deployed services used securely. This document provides guidance for deployed services
as well as for software implementations, assuming the implementer as well as for software implementations, assuming the implementer
expects his or her code to be deployed in environments defined in expects his or her code to be deployed in environments defined in
Section 5. Concerning deployment, this document targets a wide Section 5. Concerning deployment, this document targets a wide
audience -- namely, all deployers who wish to add authentication (be audience -- namely, all deployers who wish to add authentication (be
it one-way only or mutual), confidentiality, and data integrity it one-way only or mutual), confidentiality, and data integrity
protection to their communications. protection to their communications.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
record Initialization Vector (IV) for CBC-based cipher suites and record Initialization Vector (IV) for CBC-based cipher suites and
does not warn against common padding errors. This and other does not warn against common padding errors. This and other
recommendations in this section are in line with [RFC8996]. recommendations in this section are in line with [RFC8996].
* Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. * Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].
Rationale: TLS 1.1 (published in 2006) is a security improvement Rationale: TLS 1.1 (published in 2006) is a security improvement
over TLS 1.0 but still does not support certain stronger cipher over TLS 1.0 but still does not support certain stronger cipher
suites. suites.
NOTE: This recommendation has been changed from SHOULD NOT to MUST
NOT on the assumption that [I-D.ietf-tls-oldversions-deprecate]
will be published as an RFC before this document.
* Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to * Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
negotiate TLS version 1.2 over earlier versions of TLS. negotiate TLS version 1.2 over earlier versions of TLS.
Rationale: Several stronger cipher suites are available only with Rationale: Several stronger cipher suites are available only with
TLS 1.2 (published in 2008). In fact, the cipher suites TLS 1.2 (published in 2008). In fact, the cipher suites
recommended by this document for TLS 1.2 (Section 4.2 below) are recommended by this document for TLS 1.2 (Section 4.2 below) are
only available in this version. only available in this version.
* Implementations SHOULD support TLS 1.3 [RFC8446] and if * Implementations SHOULD support TLS 1.3 [RFC8446] and, if
implemented, MUST prefer to negotiate TLS 1.3 over earlier implemented, MUST prefer to negotiate TLS 1.3 over earlier
versions of TLS. versions of TLS.
Rationale: TLS 1.3 is a major overhaul to the protocol and Rationale: TLS 1.3 is a major overhaul to the protocol and
resolves many of the security issues with TLS 1.2. We note that resolves many of the security issues with TLS 1.2. We note that
as long as TLS 1.2 is still allowed by a particular as long as TLS 1.2 is still allowed by a particular
implementation, even if it defaults to TLS 1.3, implementers MUST implementation, even if it defaults to TLS 1.3, implementers MUST
still follow all the recommendations in this document. still follow all the recommendations in this document.
* Implementations of "greenfield" protocols or deployments, where * Implementations of "greenfield" protocols or deployments, where
skipping to change at page 7, line 7 skipping to change at page 7, line 5
3.1.2. DTLS Protocol Versions 3.1.2. DTLS Protocol Versions
DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS
1.1 was published. The following are the recommendations with 1.1 was published. The following are the recommendations with
respect to DTLS: respect to DTLS:
* Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347]. * Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].
Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).
* Implementations MUST support and (unless a higher version is * Implementations MUST support DTLS 1.2 [RFC6347] and MUST prefer to
available) MUST prefer to negotiate DTLS version 1.2 [RFC6347] negotiate DTLS version 1.2 over earlier versions of DTLS.
Version 1.2 of DTLS correlates to version 1.2 of TLS (see above). Version 1.2 of DTLS correlates to version 1.2 of TLS (see above).
(There is no version 1.1 of DTLS.) (There is no version 1.1 of DTLS.)
* Implementations SHOULD support and, if available, MUST prefer to * Implementations SHOULD support DTLS 1.3 [I-D.ietf-tls-dtls13] and,
negotiate DTLS version 1.3 as specified in [I-D.ietf-tls-dtls13]. if implemented, MUST prefer to negotiate DTLS version 1.3 over
earlier versions of DTLS.
Version 1.3 of DTLS correlates to version 1.3 of TLS (see above). Version 1.3 of DTLS correlates to version 1.3 of TLS (see above).
3.1.3. Fallback to Lower Versions 3.1.3. Fallback to Lower Versions
TLS/DTLS 1.2 clients MUST NOT fall back to earlier TLS versions, TLS/DTLS 1.2 clients MUST NOT fall back to earlier TLS versions,
since those versions have been deprecated [RFC8996]. We note that as since those versions have been deprecated [RFC8996]. We note that as
a result of that, the SCSV mechanism [RFC7507] is no longer needed a result of that, the SCSV mechanism [RFC7507] is no longer needed
for clients. In addition, TLS 1.3 implements a new version for clients. In addition, TLS 1.3 implements a new version
negotiation mechanism. negotiation mechanism.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
the connection. The BREACH attack is one such case. These issues the connection. The BREACH attack is one such case. These issues
can only be mitigated outside of TLS and are thus outside the scope can only be mitigated outside of TLS and are thus outside the scope
of this document. See Section 2.6 of [RFC7457] for further details. of this document. See Section 2.6 of [RFC7457] for further details.
3.4. TLS Session Resumption 3.4. TLS Session Resumption
Session resumption drastically reduces the number of TLS handshakes Session resumption drastically reduces the number of TLS handshakes
and thus is an essential performance feature for most deployments. and thus is an essential performance feature for most deployments.
Stateless session resumption with session tickets is a popular Stateless session resumption with session tickets is a popular
strategy. For TLS 1.2, it is specified in [RFC5077]. For TLS 1.3, strategy. For TLS 1.2, it is specified in [RFC5077]. For TLS 1.3, a
an equivalent PSK-based mechanism is described in Section 4.6.1 of more secure PSK-based mechanism is described in Section 4.6.1 of
[RFC8446]. When it is used, the resumption information MUST be [RFC8446]. See this post (https://blog.filippo.io/we-need-to-talk-
authenticated and encrypted to prevent modification or eavesdropping about-session-tickets/) by Filippo Valsorda for a comparison of TLS
by an attacker. Further recommendations apply to session tickets: 1.2 and 1.3 session resumption, and [Springall16] for a quantitative
study of TLS cryptographic "shortcuts", including session resumption.
When it is used, the resumption information MUST be authenticated and
encrypted to prevent modification or eavesdropping by an attacker.
Further recommendations apply to session tickets:
* A strong cipher suite MUST be used when encrypting the ticket (as * A strong cipher suite MUST be used when encrypting the ticket (as
least as strong as the main TLS cipher suite). least as strong as the main TLS cipher suite).
* Ticket keys MUST be changed regularly, e.g., once every week, so * Ticket keys MUST be changed regularly, e.g., once every week, so
as not to negate the benefits of forward secrecy (see Section 6.3 as not to negate the benefits of forward secrecy (see Section 6.3
for details on forward secrecy). for details on forward secrecy). Old ticket keys MUST be
destroyed shortly after a new key version is made available.
* For similar reasons, session ticket validity SHOULD be limited to * For similar reasons, session ticket validity SHOULD be limited to
a reasonable duration (e.g., half as long as ticket key validity). a reasonable duration (e.g., half as long as ticket key validity).
* TLS 1.2 does not roll the session key forward within a single
session. Thus, to prevent an attack where a stolen ticket key is
used to decrypt the entire content of a session (negating the
concept of forward secrecy), a TLS 1.2 server SHOULD NOT resume
sessions that are too old, e.g. sessions that have been open
longer than two ticket key rotation periods. Note that this
implies that some server implementations might need to abort
sessions after a certain duration.
Rationale: session resumption is another kind of TLS handshake, and Rationale: session resumption is another kind of TLS handshake, and
therefore must be as secure as the initial handshake. This document therefore must be as secure as the initial handshake. This document
(Section 4) recommends the use of cipher suites that provide forward (Section 4) recommends the use of cipher suites that provide forward
secrecy, i.e. that prevent an attacker who gains momentary access to secrecy, i.e. that prevent an attacker who gains momentary access to
the TLS endpoint (either client or server) and its secrets from the TLS endpoint (either client or server) and its secrets from
reading either past or future communication. The tickets must be reading either past or future communication. The tickets must be
managed so as not to negate this security property. managed so as not to negate this security property.
TLS 1.3 provides the powerful option of forward secrecy even within a TLS 1.3 provides the powerful option of forward secrecy even within a
long-lived connection that is periodically resumed. Section 2.2 of long-lived connection that is periodically resumed. Section 2.2 of
[RFC8446] recommends that clients SHOULD send a "key_share" when [RFC8446] recommends that clients SHOULD send a "key_share" when
initiating session resumption. In order to gain forward secrecy, initiating session resumption. In order to gain forward secrecy,
this document recommends that server implementations SHOULD respond this document recommends that server implementations SHOULD respond
with a "key_share", to complete an ECDHE exchange on each session with a "key_share", to complete an ECDHE exchange on each session
resumption. resumption.
TLS session resumption introduces potential privacy issues where the TLS session resumption introduces potential privacy issues where the
server is able to track the client, in some cases indefinitely. See server is able to track the client, in some cases indefinitely. See
[Sy2018] for more details. [Sy2018] for more details.
3.5. TLS Renegotiation 3.5. Renegotiation in TLS 1.2
Where handshake renegotiation is implemented, both clients and The recommendations in this section apply to TLS 1.2 only, because
servers MUST implement the renegotiation_info extension, as defined renegotiation has been removed from TLS 1.3.
in [RFC5746]. Note: this recommendation applies to TLS 1.2 only,
because renegotiation has been removed from TLS 1.3. TLS 1.2 clients and servers MUST implement the renegotiation_info
extension, as defined in [RFC5746].
TLS 1.2 clients MUST send renegotiation_info in the Client Hello. If
the server does not acknowledge the extension, the client MUST
generate a fatal handshake_failure alert prior to terminating the
connection.
Rationale: It is not safe for a client to connect to a TLS 1.2 server
that does not support renegotiation_info, regardless of whether
either endpoint actually implements renegotiation. See also
Section 4.1 of [RFC5746].
A related attack resulting from TLS session parameters not properly A related attack resulting from TLS session parameters not properly
authenticated is Triple Handshake [triple-handshake]. To address authenticated is Triple Handshake [triple-handshake]. To address
this attack, TLS 1.2 implementations SHOULD support the this attack, TLS 1.2 implementations SHOULD support the
extended_master_secret extension defined in [RFC7627]. extended_master_secret extension defined in [RFC7627].
3.6. Post-Handshake Authentication 3.6. Post-Handshake Authentication
Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post- Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post-
handshake authentication and key update mechanisms. In the context handshake authentication and key update mechanisms. In the context
skipping to change at page 10, line 24 skipping to change at page 10, line 48
Rationale: SNI supports deployment of multiple TLS-protected virtual Rationale: SNI supports deployment of multiple TLS-protected virtual
servers on a single address, and therefore enables fine-grained servers on a single address, and therefore enables fine-grained
security for these virtual servers, by allowing each one to have its security for these virtual servers, by allowing each one to have its
own certificate. However, SNI also leaks the target domain for a own certificate. However, SNI also leaks the target domain for a
given connection; this information leak will be plugged by use of TLS given connection; this information leak will be plugged by use of TLS
Encrypted Client Hello. Encrypted Client Hello.
In order to prevent the attacks described in [ALPACA], a server that In order to prevent the attacks described in [ALPACA], a server that
does not recognize the presented server name SHOULD NOT continue the does not recognize the presented server name SHOULD NOT continue the
handshake and instead fail with a fatal-level unrecognized_name(112) handshake and instead SHOULD fail with a fatal-level
alert. Note that this recommendation updates Section 3 of [RFC6066]: unrecognized_name(112) alert. Note that this recommendation updates
"If the server understood the ClientHello extension but does not Section 3 of [RFC6066]: "If the server understood the ClientHello
recognize the server name, the server SHOULD take one of two actions: extension but does not recognize the server name, the server SHOULD
either abort the handshake by sending a fatal-level take one of two actions: either abort the handshake by sending a
unrecognized_name(112) alert or continue the handshake." It is also fatal-level unrecognized_name(112) alert or continue the handshake."
RECOMMENDED that clients abort the handshake if the server It is also RECOMMENDED that clients abort the handshake if the server
acknowledges the SNI hostname with a different hostname than the one acknowledges the SNI extension, but presents a certificate with a
sent by the client. different hostname than the one sent by the client.
3.8. Application-Layer Protocol Negotiation 3.8. Application-Layer Protocol Negotiation
TLS implementations (both client- and server-side) MUST support the TLS implementations (both client- and server-side) MUST support the
Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].
In order to prevent "cross-protocol" attacks resulting from failure In order to prevent "cross-protocol" attacks resulting from failure
to ensure that a message intended for use in one protocol cannot be to ensure that a message intended for use in one protocol cannot be
mistaken for a message for use in another protocol, servers should mistaken for a message for use in another protocol, servers should
strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:
skipping to change at page 11, line 19 skipping to change at page 11, line 43
security. As a result, it requires special attention from security. As a result, it requires special attention from
implementers on both the server and the client side. Typically this implementers on both the server and the client side. Typically this
extends to both the TLS library as well as protocol layers above it. extends to both the TLS library as well as protocol layers above it.
For use in HTTP-over-TLS, readers are referred to [RFC8470] for For use in HTTP-over-TLS, readers are referred to [RFC8470] for
guidance. guidance.
For QUIC-on-TLS, refer to Sec. 9.2 of [RFC9001]. For QUIC-on-TLS, refer to Sec. 9.2 of [RFC9001].
For other protocols, generic guidance is given in Sec. 8 and For other protocols, generic guidance is given in Sec. 8 and
Appendix E.5 of [RFC8446]. Given the complexity, we RECOMMEND to Appendix E.5 of [RFC8446]. To paraphrase Appendix E.5, applications
avoid this feature altogether unless an explicit specification exists MUST avoid this feature unless an explicit specification exists for
for the application protocol in question to clarify when 0-RTT is the application protocol in question to clarify when 0-RTT is
appropriate and secure. This can take the form of an IETF RFC, a appropriate and secure. This can take the form of an IETF RFC, a
non-IETF standard, or even documentation associated with a non- non-IETF standard, or even documentation associated with a non-
standard protocol. standard protocol.
4. Recommendations: Cipher Suites 4. Recommendations: Cipher Suites
TLS and its implementations provide considerable flexibility in the TLS and its implementations provide considerable flexibility in the
selection of cipher suites. Unfortunately, some available cipher selection of cipher suites. Unfortunately, the security of some of
suites are insecure, some do not provide the targeted security these cipher suites has degraded over time to the point where some
services, and some no longer provide enough security. Incorrectly are known to be insecure. Incorrectly configuring a server leads to
configuring a server leads to no or reduced security. This section no or reduced security. This section includes recommendations on the
includes recommendations on the selection and negotiation of cipher selection and negotiation of cipher suites.
suites.
4.1. General Guidelines 4.1. General Guidelines
Cryptographic algorithms weaken over time as cryptanalysis improves: Cryptographic algorithms weaken over time as cryptanalysis improves:
algorithms that were once considered strong become weak. Such algorithms that were once considered strong become weak. Such
algorithms need to be phased out over time and replaced with more algorithms need to be phased out over time and replaced with more
secure cipher suites. This helps to ensure that the desired security secure cipher suites. This helps to ensure that the desired security
properties still hold. SSL/TLS has been in existence for almost 20 properties still hold. SSL/TLS has been in existence for almost 20
years and many of the cipher suites that have been recommended in years and many of the cipher suites that have been recommended in
various versions of SSL/TLS are now considered weak or at least not various versions of SSL/TLS are now considered weak or at least not
skipping to change at page 13, line 5 skipping to change at page 13, line 25
Such cipher suites should be evaluated according to their Such cipher suites should be evaluated according to their
effective key length. effective key length.
* Implementations SHOULD NOT negotiate cipher suites based on RSA * Implementations SHOULD NOT negotiate cipher suites based on RSA
key transport, a.k.a. "static RSA". key transport, a.k.a. "static RSA".
Rationale: These cipher suites, which have assigned values Rationale: These cipher suites, which have assigned values
starting with the string "TLS_RSA_WITH_*", have several drawbacks, starting with the string "TLS_RSA_WITH_*", have several drawbacks,
especially the fact that they do not support forward secrecy. especially the fact that they do not support forward secrecy.
* Implementations SHOULD NOT negotiate cipher suites based on non-
ephemeral (static) finite-field Diffie-Hellman key agreement.
Rationale: These cipher suites, which have assigned values
prefixed by "TLS_DH_*", have several drawbacks, especially the
fact that they do not support forward secrecy.
* Implementations MUST support and prefer to negotiate cipher suites * Implementations MUST support and prefer to negotiate cipher suites
offering forward secrecy, such as those in the Ephemeral Diffie- offering forward secrecy. However, TLS 1.2 implementations SHOULD
Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and NOT negotiate cipher suites based on ephemeral finite-field
"ECDHE") families. Diffie-Hellman key agreement (i.e., "TLS_DHE_*" suites). This is
justified by the known fragility of the construction (see
[RACCOON]) and the limitation around negotiation, including using
[RFC7919], which has seen very limited uptake.
Rationale: Forward secrecy (sometimes called "perfect forward Rationale: Forward secrecy (sometimes called "perfect forward
secrecy") prevents the recovery of information that was encrypted secrecy") prevents the recovery of information that was encrypted
with older session keys, thus limiting the amount of time during with older session keys, thus limiting the amount of time during
which attacks can be successful. See Section 6.3 for a detailed which attacks can be successful. See Section 6.3 for a detailed
discussion. discussion.
4.2. Recommended Cipher Suites 4.2. Cipher Suites for TLS 1.2
Given the foregoing considerations, implementation and deployment of Given the foregoing considerations, implementation and deployment of
the following cipher suites is RECOMMENDED: the following cipher suites is RECOMMENDED:
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
These cipher suites are supported only in TLS 1.2 and not in earlier These cipher suites are supported only in TLS 1.2 and not in earlier
protocol versions, because they are authenticated encryption (AEAD) protocol versions, because they are authenticated encryption (AEAD)
algorithms [RFC5116]. algorithms [RFC5116].
Typically, in order to prefer these suites, the order of suites needs Typically, in order to prefer these suites, the order of suites needs
to be explicitly configured in server software. (See [BETTERCRYPTO] to be explicitly configured in server software. (See [BETTERCRYPTO]
for helpful deployment guidelines, but note that its recommendations for helpful deployment guidelines, but note that its recommendations
differ from the current document in some details.) It would be ideal differ from the current document in some details.) It would be ideal
if server software implementations were to prefer these suites by if server software implementations were to prefer these suites by
default. default.
Some devices have hardware support for AES-CCM but not AES-GCM, so Some devices have hardware support for AES-CCM but not AES-GCM, so
they are unable to follow the foregoing recommendations regarding they are unable to follow the foregoing recommendations regarding
cipher suites. There are even devices that do not support public key cipher suites. There are even devices that do not support public key
cryptography at all, but they are out of scope entirely. cryptography at all, but they are out of scope entirely.
When using ECDSA signatures for authentication of TLS peers, it is
RECOMMENDED that implementations use the NIST curve P-256. In
addition, to avoid predictable or repeated nonces (that would allow
revealing the long term signing key), it is RECOMMENDED that
implementations implement "deterministic ECDSA" as specified in
[RFC6979] and in line with the recommendations in [RFC8446].
4.2.1. Implementation Details 4.2.1. Implementation Details
Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the
first proposal to any server, unless they have prior knowledge that first proposal to any server, unless they have prior knowledge that
the server cannot respond to a TLS 1.2 client_hello message. the server cannot respond to a TLS 1.2 client_hello message.
Servers MUST prefer this cipher suite over weaker cipher suites Servers MUST prefer this cipher suite over weaker cipher suites
whenever it is proposed, even if it is not the first proposal. whenever it is proposed, even if it is not the first proposal.
Clients are of course free to offer stronger cipher suites, e.g., Clients are of course free to offer stronger cipher suites, e.g.,
using AES-256; when they do, the server SHOULD prefer the stronger using AES-256; when they do, the server SHOULD prefer the stronger
cipher suite unless there are compelling reasons (e.g., seriously cipher suite unless there are compelling reasons (e.g., seriously
degraded performance) to choose otherwise. degraded performance) to choose otherwise.
This document does not change the mandatory-to-implement TLS cipher The previous version of this document implicitly allowed the old RFC
suite(s) prescribed by TLS. To maximize interoperability, RFC 5246 5246 mandatory-to-implement cipher suite,
mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher TLS_RSA_WITH_AES_128_CBC_SHA. At the time of writing, this cipher
suite, which is significantly weaker than the cipher suites suite does not provide additional interoperability, except with
recommended here. (The GCM mode does not suffer from the same extremely old clients. As with other cipher suites that do not
weakness, caused by the order of MAC-then-Encrypt in TLS provide forward secrecy, implementations SHOULD NOT support this
[Krawczyk2001], since it uses an AEAD mode of operation.)
Implementers should consider the interoperability gain against the
loss in security when deploying the TLS_RSA_WITH_AES_128_CBC_SHA
cipher suite. Other application protocols specify other cipher cipher suite. Other application protocols specify other cipher
suites as mandatory to implement (MTI). suites as mandatory to implement (MTI).
Note that some profiles of TLS 1.2 use different cipher suites. For [RFC8422] allows clients and servers to negotiate ECDH parameters
example, [RFC6460] defines a profile that uses the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.
[RFC4492] allows clients and servers to negotiate ECDH parameters
(curves). Both clients and servers SHOULD include the "Supported (curves). Both clients and servers SHOULD include the "Supported
Elliptic Curves" extension [RFC4492]. For interoperability, clients Elliptic Curves" extension [RFC8422]. Clients and servers SHOULD
and servers SHOULD support the NIST P-256 (secp256r1) curve support the NIST P-256 (secp256r1) [RFC8422] and X25519 (x25519)
[RFC4492]. In addition, clients SHOULD send an ec_point_formats [RFC7748] curves. Note that [RFC8422] deprecates all but the
extension with a single element, "uncompressed". uncompressed point format. Therefore, if the client sends an
ec_point_formats extension, the ECPointFormatList MUST contain a
single element, "uncompressed".
4.3. Cipher Suites for TLS 1.3 4.3. Cipher Suites for TLS 1.3
This document does not specify any cipher suites for TLS 1.3. This document does not specify any cipher suites for TLS 1.3.
Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite
recommendations. recommendations.
4.4. Limits on Key Usage 4.4. Limits on Key Usage
All ciphers have an upper limit on the amount of traffic that can be All ciphers have an upper limit on the amount of traffic that can be
skipping to change at page 16, line 22 skipping to change at page 17, line 8
With regard to ECDH keys, implementers are referred to the IANA With regard to ECDH keys, implementers are referred to the IANA
"Supported Groups Registry" (former "EC Named Curve Registry"), "Supported Groups Registry" (former "EC Named Curve Registry"),
within the "Transport Layer Security (TLS) Parameters" registry within the "Transport Layer Security (TLS) Parameters" registry
[IANA_TLS], and in particular to the "recommended" groups. Curves of [IANA_TLS], and in particular to the "recommended" groups. Curves of
less than 224 bits MUST NOT be used. This recommendation is in-line less than 224 bits MUST NOT be used. This recommendation is in-line
with the latest revision of [NIST.SP.800-56A]. with the latest revision of [NIST.SP.800-56A].
When using RSA, servers SHOULD authenticate using certificates with When using RSA, servers SHOULD authenticate using certificates with
at least a 2048-bit modulus for the public key. In addition, the use at least a 2048-bit modulus for the public key. In addition, the use
of the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST of the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST
NOT be used (see [CAB-Baseline] for more details). Clients MUST NOT be used ([RFC9155], and see [CAB-Baseline] for more details).
indicate to servers that they request SHA-256, by using the Clients MUST indicate to servers that they request SHA-256, by using
"Signature Algorithms" extension defined in TLS 1.2. the "Signature Algorithms" extension defined in TLS 1.2.
4.6. Truncated HMAC 4.6. Truncated HMAC
Implementations MUST NOT use the Truncated HMAC extension, defined in Implementations MUST NOT use the Truncated HMAC extension, defined in
Section 7 of [RFC6066]. Section 7 of [RFC6066].
Rationale: the extension does not apply to the AEAD cipher suites Rationale: the extension does not apply to the AEAD cipher suites
recommended above. However it does apply to most other TLS cipher recommended above. However it does apply to most other TLS cipher
suites. Its use has been shown to be insecure in [PatersonRS11]. suites. Its use has been shown to be insecure in [PatersonRS11].
skipping to change at page 17, line 14 skipping to change at page 17, line 47
* Realtime media software and services that wish to protect Secure * Realtime media software and services that wish to protect Secure
Realtime Transport Protocol (SRTP) traffic with DTLS. Realtime Transport Protocol (SRTP) traffic with DTLS.
This document does not modify the implementation and deployment This document does not modify the implementation and deployment
recommendations (e.g., mandatory-to-implement cipher suites) recommendations (e.g., mandatory-to-implement cipher suites)
prescribed by existing application protocols that employ TLS or DTLS. prescribed by existing application protocols that employ TLS or DTLS.
If the community that uses such an application protocol wishes to If the community that uses such an application protocol wishes to
modernize its usage of TLS or DTLS to be consistent with the best modernize its usage of TLS or DTLS to be consistent with the best
practices recommended here, it needs to explicitly update the practices recommended here, it needs to explicitly update the
existing application protocol definition (one example is [TLS-XMPP], existing application protocol definition (one example is [RFC7590],
which updates [RFC6120]). which updates [RFC6120]).
Designers of new application protocols developed through the Internet Designers of new application protocols developed through the Internet
Standards Process [RFC2026] are expected at minimum to conform to the Standards Process [RFC2026] are expected at minimum to conform to the
best practices recommended here, unless they provide documentation of best practices recommended here, unless they provide documentation of
compelling reasons that would prevent such conformance (e.g., compelling reasons that would prevent such conformance (e.g.,
widespread deployment on constrained devices that lack support for widespread deployment on constrained devices that lack support for
the necessary algorithms). the necessary algorithms).
5.1. Security Services 5.1. Security Services
skipping to change at page 21, line 13 skipping to change at page 21, line 52
term keys but remains passive during the conversation. term keys but remains passive during the conversation.
Forward secrecy is generally achieved by using the Diffie-Hellman Forward secrecy is generally achieved by using the Diffie-Hellman
scheme to derive session keys. The Diffie-Hellman scheme has both scheme to derive session keys. The Diffie-Hellman scheme has both
parties maintain private secrets and send parameters over the network parties maintain private secrets and send parameters over the network
as modular powers over certain cyclic groups. The properties of the as modular powers over certain cyclic groups. The properties of the
so-called Discrete Logarithm Problem (DLP) allow the parties to so-called Discrete Logarithm Problem (DLP) allow the parties to
derive the session keys without an eavesdropper being able to do so. derive the session keys without an eavesdropper being able to do so.
There is currently no known attack against DLP if sufficiently large There is currently no known attack against DLP if sufficiently large
parameters are chosen. A variant of the Diffie-Hellman scheme uses parameters are chosen. A variant of the Diffie-Hellman scheme uses
Elliptic Curves instead of the originally proposed modular elliptic curves instead of the originally proposed modular
arithmetic. arithmetic. Given the current state of the art, elliptic-curve
Diffie-Hellman appears to be more efficient, permits shorter key
lengths, and allows less freedom for implementation errors than
finite-field Diffie-Hellman.
Unfortunately, many TLS/DTLS cipher suites were defined that do not Unfortunately, many TLS/DTLS cipher suites were defined that do not
feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This
document therefore advocates strict use of forward-secrecy-only document therefore advocates strict use of forward-secrecy-only
ciphers. ciphers.
6.4. Diffie-Hellman Exponent Reuse 6.4. Diffie-Hellman Exponent Reuse
For performance reasons, many TLS implementations reuse Diffie- For performance reasons, many TLS implementations reuse Diffie-
Hellman and Elliptic Curve Diffie-Hellman exponents across multiple Hellman and Elliptic Curve Diffie-Hellman exponents across multiple
connections. Such reuse can result in major security issues: connections. Such reuse can result in major security issues:
* If exponents are reused for too long (e.g., even more than a few * If exponents are reused for too long (in some cases, even as
hours), an attacker who gains access to the host can decrypt little as a few hours), an attacker who gains access to the host
previous connections. In other words, exponent reuse negates the can decrypt previous connections. In other words, exponent reuse
effects of forward secrecy. negates the effects of forward secrecy.
* TLS implementations that reuse exponents should test the DH public * TLS implementations that reuse exponents should test the DH public
key they receive for group membership, in order to avoid some key they receive for group membership, in order to avoid some
known attacks. These tests are not standardized in TLS at the known attacks. These tests are not standardized in TLS at the
time of writing. See [RFC6989] for recipient tests required of time of writing, although general guidance in this area is
IKEv2 implementations that reuse DH exponents. provided by [NIST.SP.800-56A] and available in many protocol
implementations.
* Under certain conditions, the use of static DH keys, or of * Under certain conditions, the use of static finite-field DH keys,
ephemeral DH keys that are reused across multiple connections, can or of ephemeral finite-field DH keys that are reused across
lead to timing attacks (such as those described in [RACCOON]) on multiple connections, can lead to timing attacks (such as those
the shared secrets used in Diffie-Hellman key exchange. described in [RACCOON]) on the shared secrets used in Diffie-
Hellman key exchange.
To address these concerns, TLS implementations SHOULD NOT use static * An "invalid curve" attack can be mounted against elliptic-curve DH
DH keys and SHOULD NOT reuse ephemeral DH keys across multiple if the victim does not verify that the received point lies on the
connections. correct curve. If the victim is reusing the DH secrets, the
attacker can repeat the probe varying the points to recover the
full secret (see [Antipa2003] and [Jager2015]).
// TODO: revisit when draft-bartle-tls-deprecate-ffdhe becomes a TLS To address these concerns:
// WG item, since it specifies MUST NOT rather than SHOULD NOT.
* TLS implementations SHOULD NOT use static finite-field DH keys and
SHOULD NOT reuse ephemeral finite-field DH keys across multiple
connections.
* Server implementations that want to reuse elliptic-curve DH keys
SHOULD either use a "safe curve" [SAFECURVES] (e.g., X25519), or
perform the checks described in [NIST.SP.800-56A] on the received
points.
6.5. Certificate Revocation 6.5. Certificate Revocation
The following considerations and recommendations represent the The following considerations and recommendations represent the
current state of the art regarding certificate revocation, even current state of the art regarding certificate revocation, even
though no complete and efficient solution exists for the problem of though no complete and efficient solution exists for the problem of
checking the revocation status of common public key certificates checking the revocation status of common public key certificates
[RFC5280]: [RFC5280]:
* Certificate revocation is an important tool when recovering from
attacks on the TLS implementation, as well as cases of misissued
certificates. TLS implementations MUST implement a strategy to
distrust revoked certificates.
* Although Certificate Revocation Lists (CRLs) are the most widely * Although Certificate Revocation Lists (CRLs) are the most widely
supported mechanism for distributing revocation information, they supported mechanism for distributing revocation information, they
have known scaling challenges that limit their usefulness (despite have known scaling challenges that limit their usefulness, despite
workarounds such as partitioned CRLs and delta CRLs). workarounds such as partitioned CRLs and delta CRLs. The more
modern [CRLite] and the follow-on Let's Revoke [LetsRevoke] build
on the availability of Certificate Transparency [RFC9162] logs and
aggressive compression to allow practical use of the CRL
infrastructure, but at the time of writing, neither solution is
deployed for client-side revocation processing at scale.
* Proprietary mechanisms that embed revocation lists in the Web * Proprietary mechanisms that embed revocation lists in the Web
browser's configuration database cannot scale beyond a small browser's configuration database cannot scale beyond a small
number of the most heavily used Web servers. number of the most heavily used Web servers.
* The On-Line Certification Status Protocol (OCSP) [RFC6960] * The On-Line Certification Status Protocol (OCSP) [RFC6960] in its
presents both scaling and privacy issues. In addition, clients basic form presents both scaling and privacy issues. In addition,
typically "soft-fail", meaning that they do not abort the TLS clients typically "soft-fail", meaning that they do not abort the
connection if the OCSP server does not respond. (However, this TLS connection if the OCSP server does not respond. (However,
might be a workaround to avoid denial-of-service attacks if an this might be a workaround to avoid denial-of-service attacks if
OCSP responder is taken offline.) an OCSP responder is taken offline.). For an up-to-date survey of
the status of OCSP deployment in the Web PKI see [Chung18].
* The TLS Certificate Status Request extension (Section 8 of * The TLS Certificate Status Request extension (Section 8 of
[RFC6066]), commonly called "OCSP stapling", resolves the [RFC6066]), commonly called "OCSP stapling", resolves the
operational issues with OCSP. However, it is still ineffective in operational issues with OCSP. However, it is still ineffective in
the presence of a MITM attacker because the attacker can simply the presence of a MITM attacker because the attacker can simply
ignore the client's request for a stapled OCSP response. ignore the client's request for a stapled OCSP response.
* OCSP stapling as defined in [RFC6066] does not extend to * [RFC7633] defines a certificate extension that indicates that
intermediate certificates used in a certificate chain. Although clients must expect stapled OCSP responses for the certificate and
the Multiple Certificate Status extension [RFC6961] addresses this must abort the handshake ("hard-fail") if such a response is not
shortcoming, it is a recent addition without much deployment. available.
* Both CRLs and OCSP depend on relatively reliable connectivity to * OCSP stapling as used in TLS 1.2 does not extend to intermediate
the Internet, which might not be available to certain kinds of certificates within a certificate chain. The Multiple Certificate
nodes (such as newly provisioned devices that need to establish a Status extension [RFC6961] addresses this shortcoming, but it has
secure connection in order to boot up for the first time). seen little deployment and had been deprecated by [RFC8446]. As a
result, we no longer recommend this extension for TLS 1.2.
With regard to common public key certificates, servers SHOULD support * TLS 1.3 (Section 4.4.2.1 of [RFC8446]) allows the association of
the following as a best practice given the current state of the art OCSP information with intermediate certificates by using an
and as a foundation for a possible future solution: extension to the CertificateEntry structure. However using this
facility remains impractical because many CAs either do not
publish OCSP for CA certificates or publish OCSP reports with a
lifetime that is too long to be useful.
1. OCSP [RFC6960] * Both CRLs and OCSP depend on relatively reliable connectivity to
2. Both the status_request extension defined in [RFC6066] and the the Internet, which might not be available to certain kinds of
status_request_v2 extension defined in [RFC6961] (This might nodes. A common example is newly provisioned devices that need to
enable interoperability with the widest range of clients.) establish a secure connection in order to boot up for the first
time.
3. The OCSP stapling extension defined in [RFC6961] For the common use cases of public key certificates in TLS, servers
SHOULD support the following as a best practice given the current
state of the art and as a foundation for a possible future solution:
OCSP [RFC6960] and OCSP stapling using the status_request extension
defined in [RFC6066]. Note that the exact mechanism for embedding
the status_request extension differs between TLS 1.2 and 1.3. As a
matter of local policy, server operators MAY request that CAs issue
must-staple [RFC7633] certificates for the server and/or for client
authentication, but we recommend to review the operational conditions
before deciding on this approach.
The considerations in this section do not apply to scenarios where The considerations in this section do not apply to scenarios where
the DANE-TLSA resource record [RFC6698] is used to signal to a client the DANE-TLSA resource record [RFC6698] is used to signal to a client
which certificate a server considers valid and good to use for TLS which certificate a server considers valid and good to use for TLS
connections. connections.
7. Acknowledgments 7. Acknowledgments
The following acknowledgments are inherited from [RFC7525]. Thanks to Alexey Melnikov, Andrei Popov, Christian Huitema, Daniel
Kahn Gillmor, David Benjamin, Eric Rescorla, Hannes Tschofenig,
Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen Hubert Kario, Ilari Liusvaara, John Mattsson, John R Levine, Julien
Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson Élie, Martin Thomson, Mohit Sahni, Nick Sullivan, Nimrod Aviram, Rich
Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, Salz, Ryan Sleevi, Sean Turner, Valery Smyslov, Viktor Dukhovni for
Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom helpful comments and discussions that have shaped this document.
Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean
Turner, and Aaron Zauner for their feedback and suggested
improvements. Thanks also to Brian Smith, who has provided a great
resource in his "Proposal to Change the Default TLS Ciphersuites
Offered by Browsers" [Smith2013]. Finally, thanks to all others who
commented on the TLS, UTA, and other discussion lists but who are not
mentioned here by name.
Robert Sparks and Dave Waltermire provided helpful reviews on behalf
of the General Area Review Team and the Security Directorate,
respectively.
During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins,
Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick
provided comments that led to further improvements.
Ralph Holz gratefully acknowledges the support by Technische The authors gratefully acknowledge the contribution of Ralph Holz,
Universitaet Muenchen. who was a coauthor of RFC 7525, the previous version of this
document.
The authors gratefully acknowledge the assistance of Leif Johansson See RFC 7525 for additional acknowledgments for the previous revision
and Orit Levin as the working group chairs and Pete Resnick as the of this document.
sponsoring Area Director.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-httpbis-semantics] [I-D.ietf-httpbis-semantics]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-19, 12 September 2021, httpbis-semantics-19, 12 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-httpbis- <https://www.ietf.org/archive/id/draft-ietf-httpbis-
semantics-19.txt>. semantics-19.txt>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, dtls13-43, 30 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls- <https://www.ietf.org/archive/id/draft-ietf-tls-
dtls13-43.txt>. dtls13-43.txt>.
[I-D.ietf-tls-oldversions-deprecate]
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", Work in Progress, Internet-Draft, draft-ietf-tls-
oldversions-deprecate-12, 21 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-
oldversions-deprecate-12.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004, RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>. <https://www.rfc-editor.org/info/rfc3766>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006,
<https://www.rfc-editor.org/info/rfc4492>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
skipping to change at page 25, line 35 skipping to change at page 26, line 35
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
2011, <https://www.rfc-editor.org/info/rfc6176>. 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015, DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/info/rfc7465>. <https://www.rfc-editor.org/info/rfc7465>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>. <https://www.rfc-editor.org/info/rfc7627>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
DOI 10.17487/RFC8740, February 2020, DOI 10.17487/RFC8740, February 2020,
<https://www.rfc-editor.org/info/rfc8740>. <https://www.rfc-editor.org/info/rfc8740>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>. <https://www.rfc-editor.org/info/rfc8996>.
[RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2",
RFC 9155, DOI 10.17487/RFC9155, December 2021,
<https://www.rfc-editor.org/info/rfc9155>.
8.2. Informative References 8.2. Informative References
[ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D., [ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D.,
Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel, Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel,
"ALPACA: Application Layer Protocol Confusion - Analyzing "ALPACA: Application Layer Protocol Confusion - Analyzing
and Mitigating Cracks in TLS Authentication", 30th USENIX and Mitigating Cracks in TLS Authentication", 30th USENIX
Security Symposium (USENIX Security 21) , 2021, Security Symposium (USENIX Security 21) , 2021,
<https://www.usenix.org/conference/usenixsecurity21/ <https://www.usenix.org/conference/usenixsecurity21/
presentation/brinkmann>. presentation/brinkmann>.
[Antipa2003]
Antipa, A., Brown, D.R.L., Menezes, A., Struik, R., and
S.A. Vanstone, "Validation of Elliptic Curve Public Keys",
Public Key Cryptography - PKC 2003 , 2003.
[BETTERCRYPTO] [BETTERCRYPTO]
bettercrypto.org, "Applied Crypto Hardening", April 2015, bettercrypto.org, "Applied Crypto Hardening", April 2015,
<https://bettercrypto.org/>. <https://bettercrypto.org/>.
[Boeck2016] [Boeck2016]
Böck, H., Zauner, A., Devlin, S., Somorovsky, J., and P. Böck, H., Zauner, A., Devlin, S., Somorovsky, J., and P.
Jovanovic, "Nonce-Disrespecting Adversaries: Practical Jovanovic, "Nonce-Disrespecting Adversaries: Practical
Forgery Attacks on GCM in TLS", May 2016, Forgery Attacks on GCM in TLS", May 2016,
<https://eprint.iacr.org/2016/475.pdf>. <https://eprint.iacr.org/2016/475.pdf>.
[CAB-Baseline] [CAB-Baseline]
CA/Browser Forum, "Baseline Requirements for the Issuance CA/Browser Forum, "Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates Version and Management of Publicly-Trusted Certificates Version
1.1.6", 2013, <https://www.cabforum.org/documents.html>. 1.1.6", 2013, <https://www.cabforum.org/documents.html>.
[Chung18] Chung, T., Lok, J., Chandrasekaran, B., Choffnes, D.,
Levin, D., Maggs, B., Mislove, A., Rula, J., Sullivan, N.,
and C. Wilson, "Is the Web Ready for OCSP Must-Staple?",
Proceedings of the Internet Measurement Conference 2018,
DOI 10.1145/3278532.3278543, October 2018,
<https://doi.org/10.1145/3278532.3278543>.
[CRLite] Larisch, J., Choffnes, D., Levin, D., Maggs, B., Mislove,
A., and C. Wilson, "CRLite: A Scalable System for Pushing
All TLS Revocations to All Browsers", 2017 IEEE Symposium
on Security and Privacy (SP), DOI 10.1109/sp.2017.17, May
2017, <https://doi.org/10.1109/sp.2017.17>.
[CVE] MITRE, "Common Vulnerabilities and Exposures", [CVE] MITRE, "Common Vulnerabilities and Exposures",
<https://cve.mitre.org>. <https://cve.mitre.org>.
[DANE-SMTP] [DANE-SMTP]
Dukhovni, V. and W. Hardaker, "SMTP Security via Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, (DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015,
<https://www.rfc-editor.org/info/rfc7672>. <https://www.rfc-editor.org/info/rfc7672>.
skipping to change at page 27, line 44 skipping to change at page 29, line 39
13.txt>. 13.txt>.
[I-D.irtf-cfrg-aead-limits] [I-D.irtf-cfrg-aead-limits]
Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
AEAD Algorithms", Work in Progress, Internet-Draft, draft- AEAD Algorithms", Work in Progress, Internet-Draft, draft-
irtf-cfrg-aead-limits-03, 12 July 2021, irtf-cfrg-aead-limits-03, 12 July 2021,
<https://www.ietf.org/archive/id/draft-irtf-cfrg-aead- <https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-
limits-03.txt>. limits-03.txt>.
[IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters", [IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters",
<http://www.iana.org/assignments/tls-parameters>. <https://www.iana.org/assignments/tls-parameters>.
[Jager2015]
Jager, T., Schwenk, J., and J. Somorovsky, "Practical
Invalid Curve Attacks on TLS-ECDH", European Symposium on
Research in Computer Security (ESORICS) 2015 , 2015.
[Joux2006] Joux, A., "Authentication Failures in NIST version of [Joux2006] Joux, A., "Authentication Failures in NIST version of
GCM", 2006, <https://csrc.nist.gov/csrc/media/projects/ GCM", 2006, <https://csrc.nist.gov/csrc/media/projects/
block-cipher-techniques/documents/bcm/comments/800-38- block-cipher-techniques/documents/bcm/comments/800-38-
series-drafts/gcm/joux_comments.pdf>. series-drafts/gcm/joux_comments.pdf>.
[Kleinjung2010] [Kleinjung2010]
Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thomé, Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thomé,
E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P., E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P.,
Osvik, D., te Riele, H., Timofeev, A., and P. Zimmermann, Osvik, D., te Riele, H., Timofeev, A., and P. Zimmermann,
"Factorization of a 768-Bit RSA Modulus", Advances in "Factorization of a 768-Bit RSA Modulus", Advances in
Cryptology - CRYPTO 2010 pp. 333-350, Cryptology - CRYPTO 2010 pp. 333-350,
DOI 10.1007/978-3-642-14623-7_18, 2010, DOI 10.1007/978-3-642-14623-7_18, 2010,
<https://doi.org/10.1007/978-3-642-14623-7_18>. <https://doi.org/10.1007/978-3-642-14623-7_18>.
[Krawczyk2001] [LetsRevoke]
Krawczyk, H., "The Order of Encryption and Authentication Smith, T., Dickinson, L., and K. Seamons, "Let's Revoke:
for Protecting Communications (Or: How Secure is SSL?)", Scalable Global Certificate Revocation", Proceedings 2020
CRYPTO 01, 2001, Network and Distributed System Security Symposium,
<https://www.iacr.org/archive/crypto2001/21390309.pdf>. DOI 10.14722/ndss.2020.24084, 2020,
<https://doi.org/10.14722/ndss.2020.24084>.
[Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., [Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
Green, M., Halderman, J., Heninger, N., Springall, D., Green, M., Halderman, J., Heninger, N., Springall, D.,
Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E.,
Zanella-Béguelin, S., and P. Zimmermann, "Imperfect Zanella-Béguelin, S., and P. Zimmermann, "Imperfect
Forward Secrecy: How Diffie-Hellman Fails in Practice", Forward Secrecy: How Diffie-Hellman Fails in Practice",
Proceedings of the 22nd ACM SIGSAC Conference on Computer Proceedings of the 22nd ACM SIGSAC Conference on Computer
and Communications Security, DOI 10.1145/2810103.2813707, and Communications Security, DOI 10.1145/2810103.2813707,
October 2015, <https://doi.org/10.1145/2810103.2813707>. October 2015, <https://doi.org/10.1145/2810103.2813707>.
skipping to change at page 30, line 9 skipping to change at page 32, line 14
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
DOI 10.17487/RFC6101, August 2011, DOI 10.17487/RFC6101, August 2011,
<https://www.rfc-editor.org/info/rfc6101>. <https://www.rfc-editor.org/info/rfc6101>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>. March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport
Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460,
January 2012, <https://www.rfc-editor.org/info/rfc6460>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>. <https://www.rfc-editor.org/info/rfc6797>.
skipping to change at page 30, line 34 skipping to change at page 32, line 35
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>. <https://www.rfc-editor.org/info/rfc6961>.
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
Tests for the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 6989, DOI 10.17487/RFC6989, July 2013,
<https://www.rfc-editor.org/info/rfc6989>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<https://www.rfc-editor.org/info/rfc7507>. <https://www.rfc-editor.org/info/rfc7507>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
2015, <https://www.rfc-editor.org/info/rfc7590>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for Transport Layer Security (TLS)",
RFC 7919, DOI 10.17487/RFC7919, August 2016,
<https://www.rfc-editor.org/info/rfc7919>.
[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV:
Nonce Misuse-Resistant Authenticated Encryption", Nonce Misuse-Resistant Authenticated Encryption",
RFC 8452, DOI 10.17487/RFC8452, April 2019, RFC 8452, DOI 10.17487/RFC8452, April 2019,
<https://www.rfc-editor.org/info/rfc8452>. <https://www.rfc-editor.org/info/rfc8452>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
[Smith2013] [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Smith, B., "Proposal to Change the Default TLS Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
Ciphersuites Offered by Browsers.", 2013, December 2021, <https://www.rfc-editor.org/info/rfc9162>.
<https://briansmith.org/browser-ciphersuites-01.html>.
[SAFECURVES]
Bernstein, D.J. and T. Lange, "SafeCurves: Choosing Safe
Curves for Elliptic-Curve Cryptography", December 2014,
<https://safecurves.cr.yp.to>.
[Soghoian2011] [Soghoian2011]
Soghoian, C. and S. Stamm, "Certified Lies: Detecting and Soghoian, C. and S. Stamm, "Certified Lies: Detecting and
Defeating Government Interception Attacks Against SSL", Defeating Government Interception Attacks Against SSL",
SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010, SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010,
<https://doi.org/10.2139/ssrn.1591033>. <https://doi.org/10.2139/ssrn.1591033>.
[Springall16]
Springall, D., Durumeric, Z., and J. Halderman, "Measuring
the Security Harm of TLS Crypto Shortcuts", Proceedings of
the 2016 Internet Measurement Conference,
DOI 10.1145/2987443.2987480, November 2016,
<https://doi.org/10.1145/2987443.2987480>.
[Sy2018] Sy, E., Burkert, C., Federrath, H., and M. Fischer, [Sy2018] Sy, E., Burkert, C., Federrath, H., and M. Fischer,
"Tracking Users across the Web via TLS Session "Tracking Users across the Web via TLS Session
Resumption", Proceedings of the 34th Annual Computer Resumption", Proceedings of the 34th Annual Computer
Security Applications Conference, Security Applications Conference,
DOI 10.1145/3274694.3274708, December 2018, DOI 10.1145/3274694.3274708, December 2018,
<https://doi.org/10.1145/3274694.3274708>. <https://doi.org/10.1145/3274694.3274708>.
[TLS-XMPP] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
2015, <https://www.rfc-editor.org/info/rfc7590>.
[triple-handshake] [triple-handshake]
Bhargavan, K., Lavaud, A., Fournet, C., Pironti, A., and Bhargavan, K., Lavaud, A., Fournet, C., Pironti, A., and
P. Strub, "Triple Handshakes and Cookie Cutters: Breaking P. Strub, "Triple Handshakes and Cookie Cutters: Breaking
and Fixing Authentication over TLS", 2014 IEEE Symposium and Fixing Authentication over TLS", 2014 IEEE Symposium
on Security and Privacy, DOI 10.1109/sp.2014.14, May 2014, on Security and Privacy, DOI 10.1109/sp.2014.14, May 2014,
<https://doi.org/10.1109/sp.2014.14>. <https://doi.org/10.1109/sp.2014.14>.
Appendix A. Differences from RFC 7525 Appendix A. Differences from RFC 7525
This revision of the Best Current Practices contains numerous This revision of the Best Current Practices contains numerous
skipping to change at page 32, line 31 skipping to change at page 34, line 52
- Specific guidance for multiplexed protocols. - Specific guidance for multiplexed protocols.
- MUST-level implementation requirement for ALPN, and more - MUST-level implementation requirement for ALPN, and more
specific SHOULD-level guidance for ALPN and SNI. specific SHOULD-level guidance for ALPN and SNI.
- Limits on key usage. - Limits on key usage.
- New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce- - New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce-
Disrespecting Adversaries". Disrespecting Adversaries".
- RFC 6961 (OCSP status_request_v2) has been deprecated.
* Differences specific to TLS 1.2: * Differences specific to TLS 1.2:
- SHOULD-level guidance on AES-GCM nonce generation. - SHOULD-level guidance on AES-GCM nonce generation.
- SHOULD NOT use static DH keys or reuse ephemeral DH keys across - SHOULD NOT use (static or ephemeral) finite-field DH key
multiple connections. agreement.
- SHOULD NOT reuse ephemeral finite-field DH keys across multiple
connections.
- 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192 - 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192
previously. previously.
- Support for extended_master_secret is a SHOULD. Also removed - Support for extended_master_secret is a SHOULD. Also removed
other, more complicated, related mitigations. other, more complicated, related mitigations.
- SHOULD-level restriction on the TLS session duration, depending
on the rotation period of an [RFC5077] ticket key.
- Drop TLS_DHE_RSA_WITH_AES from the recommended ciphers
- Add TLS_ECDHE_ECDSA_WITH_AES to the recommended ciphers
- SHOULD NOT use the old MTI cipher suite,
TLS_RSA_WITH_AES_128_CBC_SHA.
- Recommend curve X25519 alongside NIST P-256
* Differences specific to TLS 1.3: * Differences specific to TLS 1.3:
- New TLS 1.3 capabilities: 0-RTT. - New TLS 1.3 capabilities: 0-RTT.
- Removed capabilities: renegotiation, compression. - Removed capabilities: renegotiation, compression.
- Added mention of TLS Encrypted Client Hello, but no - Added mention of TLS Encrypted Client Hello, but no
recommendation to use until it is finalized. recommendation to use until it is finalized.
- SHOULD-level requirement for forward secrecy in TLS 1.3 session - SHOULD-level requirement for forward secrecy in TLS 1.3 session
resumption. resumption.
- Generic SHOULD-level guidance to avoid 0-RTT unless it is - Generic SHOULD-level guidance to avoid 0-RTT unless it is
documented for the particular protocol. documented for the particular protocol.
Appendix B. Document History Appendix B. Document History
// Note to RFC Editor: please remove before publication. // Note to RFC Editor: please remove before publication.
B.1. draft-ietf-uta-rfc7525bis-04 B.1. draft-ietf-uta-rfc7525bis-05
* Addressed WG Last Call comments, specifically:
- More clarity and guidance on session resumption.
- Clarity on TLS 1.2 renegotiation.
- Wording on the 0-RTT feature aligned with RFC 8446.
- SHOULD NOT guidance on static and ephemeral finite field DH
cipher suites.
- Revamped the recommended TLS 1.2 cipher suites, removing DHE
and adding ECDSA. The latter due to the wide adoption of ECDSA
certificates and in line with RFC 8446.
- Recommendation to use deterministic ECDSA.
- Finally deprecated the old TLS 1.2 MTI cipher suite.
- Deeper discussion of ECDH public key reuse issues, and as a
result, recommended support of X25519.
- Reworded the section on certificate revocation and OCSP
following a long mailing list thread.
B.2. draft-ietf-uta-rfc7525bis-04
* No version fallback from TLS 1.2 to earlier versions, therefore no * No version fallback from TLS 1.2 to earlier versions, therefore no
SCSV. SCSV.
B.2. draft-ietf-uta-rfc7525bis-03 B.3. draft-ietf-uta-rfc7525bis-03
* Cipher integrity and confidentiality limits. * Cipher integrity and confidentiality limits.
* Require extended_master_secret. * Require extended_master_secret.
B.3. draft-ietf-uta-rfc7525bis-02 B.4. draft-ietf-uta-rfc7525bis-02
* Adjusted text about ALPN support in application protocols * Adjusted text about ALPN support in application protocols
* Incorporated text from draft-ietf-tls-md5-sha1-deprecate * Incorporated text from draft-ietf-tls-md5-sha1-deprecate
B.4. draft-ietf-uta-rfc7525bis-01 B.5. draft-ietf-uta-rfc7525bis-01
* Many more changes, including: * Many more changes, including:
- SHOULD-level requirement for forward secrecy in TLS 1.3 session - SHOULD-level requirement for forward secrecy in TLS 1.3 session
resumption. resumption.
- Removed TLS 1.2 capabilities: renegotiation, compression. - Removed TLS 1.2 capabilities: renegotiation, compression.
- Specific guidance for multiplexed protocols. - Specific guidance for multiplexed protocols.
skipping to change at page 34, line 11 skipping to change at page 37, line 26
documented for the particular protocol. documented for the particular protocol.
- SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. - SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2.
- SHOULD NOT use static DH keys or reuse ephemeral DH keys across - SHOULD NOT use static DH keys or reuse ephemeral DH keys across
multiple connections. multiple connections.
- 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from - 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from
192. 192.
B.5. draft-ietf-uta-rfc7525bis-00 B.6. draft-ietf-uta-rfc7525bis-00
* Renamed: WG document. * Renamed: WG document.
* Started populating list of changes from RFC 7525. * Started populating list of changes from RFC 7525.
* General rewording of abstract and intro for revised version. * General rewording of abstract and intro for revised version.
* Protocol versions, fallback. * Protocol versions, fallback.
* Reference to ECHO. * Reference to ECHO.
B.6. draft-sheffer-uta-rfc7525bis-00 B.7. draft-sheffer-uta-rfc7525bis-00
* Renamed, since the BCP number does not change. * Renamed, since the BCP number does not change.
* Added an empty "Differences from RFC 7525" section. * Added an empty "Differences from RFC 7525" section.
B.7. draft-sheffer-uta-bcp195bis-00 B.8. draft-sheffer-uta-bcp195bis-00
* Initial release, the RFC 7525 text as-is, with some minor * Initial release, the RFC 7525 text as-is, with some minor
editorial changes to the references. editorial changes to the references.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
Email: yaronf.ietf@gmail.com Email: yaronf.ietf@gmail.com
Ralph Holz
University of Twente
Email: ralph.ietf@gmail.com
Peter Saint-Andre Peter Saint-Andre
Mozilla Mozilla
Email: stpeter@mozilla.com Email: stpeter@mozilla.com
Thomas Fossati Thomas Fossati
arm arm
Email: thomas.fossati@arm.com Email: thomas.fossati@arm.com
 End of changes. 84 change blocks. 
255 lines changed or deleted 400 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/