Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-uta-tls-bcp-11

[Ballot discuss]
I really can't abide by the abdication in Section 5.2.  Getting a cert is hard.  Running reasonably recent software and configuring it properly is not.  The possibility that a connection will not be authenticated is no excuse for using bad versions of TLS or using insecure ciphersuites.

I appreciate that normally deference to WG consensus is appropriate, but this is a recommendation that could be actively harmful to the Internet by encouraging the continued use of broken code.

[Ballot comment]
These COMMENTs are right on the edge of being  DISCUSS points, because I think there are some pretty critical references missing.  Please consider this a COMMENT of Unusual Strength.

Section 1. "which together are the most widely deployed ciphers"

Actually, at least in the web context, this isn't totally true.  According to Firefox telemetry, AES-GCM has been the most widely deployed cipher since at least 3Q14, and is currently used in the majority of TLS handshakes that Firefox does (52%) [1].


Section 3.1.1. Implementations MUST NOT negotiate SSL version 3

A reference to draft-ietf-tls-sslv3-diediedie seems in order here.


Section 3.1.

It would be good for this section to mention that servers MUST implement TLS version negotiation.  That is, they MUST NOT abort the handshake if the version offered by the client is higher than the version the server supports.  This is, after all, the root cause of fallback. 


Section 3.1.3.

I'm surprised that there's not even a SHOULD CONSIDER [RFC6919] for SCSV here.  Did the WG discuss having any requirement for SCSV?

Also, if you want a cite for the 3% number, it's in the proceedings of IETF 91 [2].


Section 3.3.

You might point out HPACK [3] as an example of compression that is sensitive to things like CRIME.


Section 3.5.

Shouldn't this refer more specifically to draft-ietf-tls-session-hash [4]?  As it is, the recommendations in this section are kind of vacuous; e.g., TLS without session-hash provides no way to "bind the master secret to the full handshake".


Section 4.4. "Modular vs. Elliptic Curve"

I think that "finite field" or "modp" are more common than "modular".



[1] http://mzl.la/1AmwXsm
[2] http://www.ietf.org/proceedings/91/slides/slides-91-saag-3.pdf
[3] https://tools.ietf.org/html/draft-ietf-httpbis-header-compression
[4] https://tools.ietf.org/html/draft-ietf-tls-session-hash

[Ballot discuss]
One very simple point:

-- Section 2 --

  A number of security-related terms in this document are used in the
  sense defined in [RFC4949].

Terminology definitions need to be in normative references; 4949 should be normative.

[Ballot comment]
I don't want to make these a DISCUSS, but I would appreciate a discussion:

-- Section 3.1.1 --
On the SHOULD NOTs here: Is there any reason one might violate them *other than* that the other side doesn't support TLS 1.2 ?  If not, is it worth saying that explicitly?  Is it even worth changing "SHOULD NOT negotiate TLS version [x]" to "MUST NOT negotiate TLS version [x] unless no higher version is available in the negotiation" ?

How can I evaluate each of the following "SHOULD"s?  Why might I have a good reason not to comply with each of them?:

-- Section 3.2 --

  o  When applicable, Web servers SHOULD use HSTS to indicate that they
      are willing to accept TLS-only clients.

-- Section 3.3 --

  Implementations and deployments SHOULD disable TLS-level compression
  ([RFC5246], Section 6.2.2).

-- Section 3.5 --

  TLS clients
  SHOULD apply the same validation policy for all certificates received
  over a connection, bind the master secret to the full handshake, and
  bind the abbreviated session resumption handshake to the original
  full handshake.

-- Section 4.2.1 --

  Servers SHOULD prefer this cipher suite over weaker cipher suites
  whenever it is proposed, even if it is not the first proposal.

For the above set of "SHOULD" questions, I'm looking for something in the document that can help readers understand why these are not "MUST", and when and why they might make an informed decision not to abide by them.

---

One other non-blocking comment; no discussion needed:

-- Section 3.1.2 --
Nit: "correlates to Version 1.2 of TLS 1.2" -- take out one of the "1.2" ?

[Ballot comment]
Thanks for your work on this very helpful draft!

I just have a few comments/questions.


Section 5. Applicability statement:
Should this include application authors (mentioned in section 7.1) and Developers who can set the defaults for implementations of TLS to help operators that are mentioned in this applicability statement?  I see the sentence is phrased for 'deployment recommendations', but maybe this should also have a sentence or two on development recommendations.

Not for this draft, but this one raised a question for me.
Section 7.3: If you look at the following text:
  Unfortunately, many TLS/DTLS cipher suites were defined that do not
  feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256.  This
  document therefore advocates strict use of forward-secrecy-only
  ciphers.
Should we be thinking about updates to the TLS registry to reflect this recommendation?  That's probably not this draft, but a follow on to provide the needed 'specification required'.  I'm sure a lot more thought might be needed for that and maybe support for features like PFS is added in a table if older recommendations that don't meet this are not removed.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

HTTPbis went to the trouble of creating a blacklist of cipher suites that includes ones in the TLS registry.  They did take the MTI recommendation that is in this draft, which is good.  See section 9.2 and appendix A.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/

[Ballot discuss]
Thanks for all your work on this.

I have a quick question about how we expect this document to be used within the IETF. I note that the bulk of the requirements/recommendations are directed at implementers, not protocol designers/specs. And Section 4.2.1 also says:

"This document does not change the mandatory-to-implement TLS cipher
  suite(s) prescribed by TLS or application protocols using TLS. ...
  Implementers should consider the interoperability gain against the
  loss in security when deploying that cipher suite.  Other application
  protocols specify other cipher suites as mandatory to implement
  (MTI)."

So my question is whether we should consider this document effectively silent about the choice of cipher suites to be used when we standardize a new application protocol in the IETF, or an update to an existing protocol. That is the impression that I get from the text right now, and it doesn't quite match the way we've been using/citing the document in some recent discussions of other drafts. On the other hand, if we're expecting new or updated application protocol specs to conform to or take into account the recommendations in this document, I think that should be made more clear.

[Ballot comment]
-- Sec 4.1:
128-bit ciphers are expected to remain secure for at least several years, and
      256-bit ciphers "until the next fundamental technology
      breakthrough".
   
Is the quoted text quoting something? If not, why is it in quotes?

-- Sec 5:
Although the list here is non-exhaustive, it seems odd to me that no DTLS examples are listed.

[Ballot comment]
This is great. Thanks for putting it together.

Just for my own edification, why would

  o  Implementations MUST support, and SHOULD prefer to negotiate,
      cipher suites offering forward secrecy, such as those in the
      Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie-
      Hellman ("DHE" and "ECDHE") families.

not also be "MUST prefer to negotiate"?

I found it strange that there's no hint of

5.2.  Unauthenticated TLS and Opportunistic Security

  In summary: this document does not apply to unauthenticated TLS use
  cases.

until about halfway through page 15. If it's important to say this, maybe it's better to say it earlier in the document?

[Ballot comment]

I've a bunch of nits below. The only non-bit is whether or
not this has recently been compared to bettercrypto.org.
Doing so again would be a fine thing if not.

- abstract & intro: nit: maybe s/and modes of
operation/and their modes of operation/ might be better,
as modes are defined by ciphersuites

- intro: maybe s/are/have been/ when you say CBC and RC4
are most common - that's changing fairly quickly

- intro: maybe s/will have/should have/ fewer vulns. when
deploying TLS1.3 - we can't control code quality

- 3.2: SSL stripping could do with a reference maybe

- 3.3: If it is true that compression attacks require the
attacker to control the traffic, then saying so would be
good, but only if there's an easily understood way to
phrase that, and I can't think of one right now;-)

- 3.6: add a reference to where SNI is defined (that's RFC
6066, section 3 I think?)

- section 4: would a reference to bettercrypto.org be good
here - they have specific configs one can use to implement
these recommendations (or at least I hope they do!)

- 4.1: I forget if the WG discussed adding a SHOULD NOT
for RSA key transport. I think that'd be a fine addition,
along with a statement that the justification is the lack
of PFS.

- 4.2.1: nitty, nit, nit: they MTI acronym should be
defined on 1st use, not 2nd:-)

- 4.4: "negotiated parameters" reads somewhat ambiguously
as it could be read to mean chinese menu, and I don't
think that's what you want

- 7.1: did anyone compare this text to the "most dangerous
code" paper? [1] [1]
http://dl.acm.org/citation.cfm?id=2382204

- 7.3: "aka PKIX certificates" isn't correct, I'd delete
the phrase (but leave the ref to 5280) both times

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-uta-tls-bcp-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Recommendations for Secure Use of TLS and DTLS) to Best Current Practice


The IESG has received a request from the Using TLS in Applications WG
(uta) to consider the following document:
- 'Recommendations for Secure Use of TLS and DTLS'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Transport Layer Security (TLS) and Datagram Transport Layer Security
  (DTLS) are widely used to protect data exchanged over application
  protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
  last few years, several serious attacks on TLS have emerged,
  including attacks on its most commonly used cipher suites and modes
  of operation.  This document provides recommendations for improving
  the security of deployed services that use TLS and DTLS.  The
  recommendations are applicable to the majority of use cases.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary
The document shepherd is Orit Levin. The responsible Area Director is Pete Resnick.
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.
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.
2. Review and Consensus
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.
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.
3. Intellectual Property
Each author has stated that according to their personal knowledge no IPR related to this document exists. No IPRs have been mentioned during UTA WG discussions.
4. Other Points
This document requests no actions of IANA.

1. Summary
The document shepherd is Orit Levin. The responsible Area Director is Pete Resnick.
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.
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.
2. Review and Consensus
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.
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.
3. Intellectual Property
Each author has stated that according to their personal knowledge no IPR related to this document exists. No IPRs have been mentioned during UTA WG discussions.
4. Other Points
This document requests no actions of IANA.
Checklist to Be Removed
This section is not meant to be submitted, but is here as a useful checklist of things the document shepherd is expected to have verified before publication is requested from the responsible Area Director. If the answers to any of these is "no", please explain the situation in the body of the writeup.
• Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
• Is the intent of the document accurately and adequately explained in the introduction?
• Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? (In general, nits should be fixed before the document is sent to the IESG. If there are reasons that some remain (false positives, perhaps, or abnormal things that are necessary for this particular document), explain them.)
• Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? (Note any downward references (see RFC 3967) and whether they appear in the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these need to be announced during Last Call. )
• Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
• If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?