On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <mackerm...@bcbsm.com> wrote: > I am not sure I understand what your reply means? > > Is it that we should create or even allow an environment to develop, where > all providers of service cannot provide effective diagnostics and support? > And then see the constituents of these industries collapse together. And > only then realize we have an issue? > I hope I am not understanding correctly. IETF is supposed to be looking > ahead to provide better answers and circumvent predictable problems. Not > ignoring, waiting and then reacting to negative situations that can and > should be avoided.
What exactly is the problem you are concerned with? As I've pointed out previously one can still log the contents of TLS protected connections: you do this at the client, or with an intercepting proxy. What information does this not get you that you need on the network? > > What I am saying, in relation to your "Delivering a stable product" comment > is that over time various industries have learned what it takes to "Deliver a > stable product". We did not want to invest millions in these debugging > networks. But we learned the hard way, that it was necessary. > I am not a member of the banking coalition that started this subject, nor of > the banking industry at all, but I certainly understand their perspective > and am concerned about the same unmanageable future they described. Do Akami, Cloudlflare and Google magically not have these problems? > > Thanks > > Mike > > > > -----Original Message----- > From: Jeffrey Walton [mailto:noloa...@gmail.com] > Sent: Friday, September 23, 2016 10:55 AM > To: Ackermann, Michael <mackerm...@bcbsm.com> > Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> > wrote: >> From the perspective an Enterprise that runs these applications and has >> invested HEAVILY in the debugging networks......... >> >> The reason we are debugging these networks is so that "The 5-6 order of >> magnitude of folks using them" will have good service. If they do not, >> they will consider competitors and/or generate a litany service calls or >> complaints. I.E. When these "Folks" are slow or not working they >> are just as unhappy as we are. >> > > Isn't that the market operating as expected? Those who deliver a stable > product at a competitive price are rewarded, while those who fail to deliver > or deliver at an unreasonable cost are not? (Some hand waiving). > > If all providers failed to deliver or delivered an inferior product, then it > might indicate a major course correction is needed. But I don't think that's > the case here. > > Jeff > > > 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 -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
