Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, uta mailing list <firstname.lastname@example.org>, uta chair <email@example.com> 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 Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
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 https://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/). 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 http://www.ietf.org/mail-archive/web/uta/current/maillist.html 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 future. 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 (https://tools.ietf.org/html/draft-ietf-dice-profile-08). 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. Personnel The document shepherd is Orit Levin. The responsible Area Director is Pete Resnick.