Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
RFC 7525

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    uta mailing list <>,
    uta chair <>
Subject: Protocol Action: 'Recommendations for Secure Use of TLS and DTLS' to Best Current Practice (draft-ietf-uta-tls-bcp-11.txt)

The IESG has approved the following document:
- 'Recommendations for Secure Use of TLS and DTLS'
  (draft-ietf-uta-tls-bcp-11.txt) as Best Current Practice

This document is the product of the Using TLS in Applications Working

The IESG contact persons are Pete Resnick and Barry Leiba.

A URL of this Internet Draft is:

Technical Summary

   This document provides guidance for implementing and using Transport
   Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
   protocols in order to ensure authentication, confidentiality, and
   data integrity protection to communications exchanged over a broad
   range of application protocols that desire these properties. It is
   expected that applications' communities consult this document before
   stating application-specific recommendations on a case-by-case basis
   if needed.

Working Group Summary

   This document is requested to be published as a BCP. It lists and
   explains the rationale for the best existing practices known to
   protect against a growing number of security attacks against TLS and
   DTLS. (These attacks are documented in a companion document  For
   example, this document calls for the deployment of algorithms that
   are typically implemented by TLS and DTLS software, but not yet
   widely used by applications.

   There has been a strong consensus on the UTA list (and beyond) that
   the information in this document is extremely timely and valuable to
   the broad community and that the document needs to be published as
   soon as possible. Comments have been made about the applicability of
   this document after TLS 1.3 is published and deployed. A system that
   deploys TLS 1.3 will have fewer vulnerabilities than TLS 1.2 or
   below, but the strength of various algorithms and the feasibility of
   known and new attacks is a point-in-time statement. This document is
   likely to be updated after TLS 1.3 gets noticeable deployment.

Document Quality

   The document has been thoroughly reviewed by a long string of
   security and applications' experts for its content and readability.
   For reference, please see the year-long active discussion on the and
   the "Acknowledgements" section of the document. There has been a
   number of topics that generated extensive discussions on the list and
   resulting in a consensus. The exact choice of the recommended cipher
   suites has been discussed in length in order to find the right
   balance between achieving security and interoperability. The
   conclusion has been captured in section 4.2 of the document.
   Determining the requirements of a typical application using TLS or
   DTLS have been discussed at length and led to writing the
   "applicability statement" in section 5 of the document. As a result,
   applications that intentionally choose not to rely on the
   authentication, confidentiality, or data integrity properties
   provided by TLS and DTLS don't need to follow the recommendations of
   this document.  Specifically, the cases of "unauthenticated TLS" or
   "opportunistic security" are not covered in this document leaving the
   opportunity to write TLS/DTLS recommendations for these cases in the

   A recent concern has been expressed on the list that readers less
   involved in the IETF get confused by having four recommendations for
   using TLS/DTLS: the TLS spec, the Constrained Application Protocol
   (CoAP) spec, the UTA BCP (i.e., this document), and the DTLS Profile
   for Internet of Things
   ( To address
   this concern, it is important to note that (1) this document doesn't
   profile neither TLS nor DTLS (e.g., it does not change their MTI
   algorithms); (2) IoT and CoAP define a particular application
   environment with its specific profile(s) to be followed by its
   community; and (3) we hope that CoAP and DICE community find the
   information captured in this document as a useful input to their work.


   The document shepherd is Orit Levin.
   The responsible Area Director is Pete Resnick.