Skip to main content

5. Applicability Statement

The recommendations of this document primarily apply to the implementation and deployment of application protocols that are most commonly used with TLS and DTLS on the Internet today. Examples include, but are not limited to:

  • Web software and services that wish to protect HTTP traffic with TLS.

  • Email software and services that wish to protect IMAP, Post Office Protocol version 3 (POP3), or SMTP traffic with TLS.

  • Instant-messaging software and services that wish to protect Extensible Messaging and Presence Protocol (XMPP) or Internet Relay Chat (IRC) traffic with TLS.

  • Realtime media software and services that wish to protect Secure Realtime Transport Protocol (SRTP) traffic with DTLS.

This document does not modify the implementation and deployment recommendations (e.g., mandatory-to-implement cipher suites) prescribed by existing application protocols that employ TLS or DTLS. If the community that uses such an application protocol wishes to modernize its usage of TLS or DTLS to be consistent with the best practices recommended here, it needs to explicitly update the existing application protocol definition (one example is [RFC7590], which updates [RFC6120]).

Designers of new application protocols developed through the Internet Standards Process [RFC2026] are expected at minimum to conform to the best practices recommended here, unless they provide documentation of compelling reasons that would prevent such conformance (e.g., widespread deployment on constrained devices that lack support for the necessary algorithms).

Although many of the recommendations provided here might also apply to QUIC insofar that it uses the TLS 1.3 handshake protocol, QUIC and other such secure transport protocols are out of scope of this document. For QUIC specifically, readers are referred to Section 9.2 of [RFC9001].

This document does not address the use of TLS in constrained-node networks [RFC7228]. For recommendations regarding the profiling of TLS and DTLS for small devices with severe constraints on power, memory, and processing resources, the reader is referred to [RFC7925] and [IOT-PROFILE].

5.1. Security Services​

This document provides recommendations for an audience that wishes to secure their communication with TLS to achieve the following:

Confidentiality: all application-layer communication is encrypted with the goal that no party should be able to decrypt it except the intended receiver.

Data integrity: any changes made to the communication in transit are detectable by the receiver.

Authentication: an endpoint of the TLS communication is authenticated as the intended entity to communicate with.

With regard to authentication, TLS enables authentication of one or both endpoints in the communication. In the context of opportunistic security [RFC7435], TLS is sometimes used without authentication. As discussed in Section 5.2, considerations for opportunistic security are not in scope for this document.

If deployers deviate from the recommendations given in this document, they need to be aware that they might lose access to one of the foregoing security services.

This document applies only to environments where confidentiality is required. It requires algorithms and configuration options that enforce secrecy of the data in transit.

This document also assumes that data integrity protection is always one of the goals of a deployment. In cases where integrity is not required, it does not make sense to employ TLS in the first place. There are attacks against confidentiality-only protection that utilize the lack of integrity to also break confidentiality (see, for instance, [DegabrieleP07] in the context of IPsec).

This document addresses itself to application protocols that are most commonly used on the Internet with TLS and DTLS. Typically, all communication between TLS clients and TLS servers requires all three of the above security services. This is particularly true where TLS clients are user agents like web browsers or email clients.

This document does not address the rarer deployment scenarios where one of the above three properties is not desired, such as the use case described in Section 5.2. As another scenario where confidentiality is not needed, consider a monitored network where the authorities in charge of the respective traffic domain require full access to unencrypted (plaintext) traffic and where users collaborate and send their traffic in the clear.

5.2. Opportunistic Security​

There are several important scenarios in which the use of TLS is optional, i.e., the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear. This practice, often called "opportunistic security", is described at length in [RFC7435] and is often motivated by a desire for backward compatibility with legacy deployments.

In these scenarios, some of the recommendations in this document might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome than using TLS with an outdated protocol version or cipher suite.

Last updated on