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. No one I am aware of is pushing for a MitM capability to address this. In fact it was one of the alternative solutions for which many implementation issues were cited at the Prague meeting and on this list. But I would like to ask, what is the solution that your company and others that you reference, have solved this problem by implementing? From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tony Arcieri Sent: Monday, October 23, 2017 5:43 PM To: Adam Caudill <a...@adamcaudill.com> Cc: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill <a...@adamcaudill.com<mailto: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. The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
