Subject: [Uta] Why we have a BCP

From: Watson Ladd <[email-masked]>
Date: Thu, 4 Sep 2014 17:51:26 -0700

Dear all,

At least 99% of the time, traffic goes over TLS to protect it from
prying eyes. And very often, this is not the case because of various
failures: from the lack of hostname validation, to the misuse of
ciphers in old versions, or the use of non-PFS suites and eventual key
compromise. This BCP exists to guide administrators and developers in
using TLS correctly to achieve the goals that they almost certainly
have.

Yet, people object to recommendations being made in this BCP on the
basis that they don't actually want to protect their data from prying
eyes, and thus the configurations they use won't fit into the
framework for those who actually want to protect their data. This is
exactly what the BCP is intended to do: exclude uses that are likely
to violate the expectations the naive sysadmin has of TLS.

Particularly pernicious is the argument that implementations might
ensure that all data sent through them is protected, and thus these
implementations will not permit unprotected data to go through them. I
am unsure of what the problem is with this idea: such an
implementation would eliminate a vast class of problems.

Simply put the BCP was intended to offer guidance on how to use TLS
securely: insecure configurations are outside its remit. It appears
that many members of the WG (or a few vocal ones) wish to offer
instead halfhearted alternatives to ensure the continued befuddlement
of those tasked with securing data in transit.

I want a document I can point to and say "go do that" and rest assured
that it comprehensively addresses the issues that could prevent a TLS
deployment from meeting the security notions that we expect from our
data. Making it possible to plead compliance to the letter while
dispensing with the spirit would make this reliance impossible.

To the extent that it is necessary to limit the scope of
applicability, I would prefer that this be done by stating that these
are Best Current Practices for ensuring the confidentiality and
integrity of data via TLS, and that you probably are looking into TLS
to deliver that, rather than carving out exceptions for uses that
don't ensure the confidentiality and integrity of data sent via TLS.

Sincerely,
Watson

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 5 Sep 2014 07:37:07 +0200

I think some of us said exactly that (with fewer snide remarks).

Bodo