A few observations: + TLS 1.3 is designed around the assumption that we are doing DH-style key establishment. There are good reasons for this, both in terms of protocol simplicity and in terms of establishing a baseline of strong modes (PFS, compatibility with standard uses of EC, etc.). Re-adding a key transport mode like TLS 1.2 static RSA would be extremely disruptive, even if it weren't being raised so late in the process. It's certainly not just a matter of changing some RFC 2119 language forbidding static RSA.
+ As several people have observed, there are several potential ways to build an equivalent capability that's compatible with TLS 1.3 as it currently is designed (see for instance Hugo Krawczyk's email [0]) They would of course require a different interface between the monitoring appliance and the server (i.e., you would need to export a different kind of key and use it somewhat differently on the monitoring system), but it's not significantly less efficient. -Ekr [0] As well as his caveat about analysis being needed here. On Fri, Sep 23, 2016 at 9:49 AM, Ackermann, Michael <mackerm...@bcbsm.com> wrote: > Without re stating the original message from the bank coalition, which > states this better than I could, the client and MITM solutions are not > practical in many situations. Also they do not provide the scope, depth > or detail that is utilized with today's solutions. > > -----Original Message----- > From: Watson Ladd [mailto:watsonbl...@gmail.com] > Sent: Friday, September 23, 2016 11:44 AM > To: Ackermann, Michael <mackerm...@bcbsm.com> > Cc: noloa...@gmail.com; tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > 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. > > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
