On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill <a...@adamcaudill.com> wrote:
> Those advocating for some standardized method of subverting the security > properties of TLS have been offered numerous options in good faith, and > continue to reject them all. I’m aware of extremely large enterprises that > in fact require TLS 1.2 with PFS, as they made the investment in addressing > this issue early on, and do so effectively. This can be solved without > changes to the protocol or a standardized “backdoor” - and is being done > today by at least some enterprises. > Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly disingenuous to cite the need for self-MitM capability as an "industry" concern. I think if it were possible to ask for a hum "from industry", you'd find the field divided between those who have invested in a real observability story, and those who think passive network traffic collection is the only way to debug their systems. I think if you were to even take a straw poll of the best approaches monitoring/observability among actual industry practitioners, passive network traffic collection would rank close to the bottom of the list. I would go as far as to say that if you are among those requesting this misfeature, you are doing a terrible job securing your infrastructure, and should look into modern observability techniques as an alternative to debugging by concentrating network traffic dumps into a single point of compromise which represents a huge security liability. Yes, switching to a new approach to observability is a huge investment that will take time, but so is upgrading to a new version of TLS. The "industry" reality is that many companies do not need a self-MitM misfeature and could be actively harmed by it, and while a self-MitM capability may be standard operating practice for some, it is not true for all, and identifying those who want the self-MitM capability as "industry" is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF is not listening to the concerns of industry". As a member of "industry" myself, I implore the IETF: please don't make the rest of us less secure at the request of those who are running insecure infrastructures and apparently intend on keeping things that way.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
