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 _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
