Re: [TLS] Industry Concerns about TLS 1.3

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 <MAckermann@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:watsonbladd@gmail.com]
> Sent: Friday, September 23, 2016 11:44 AM
> To: Ackermann, Michael <MAckermann@bcbsm.com>
> Cc: noloader@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 <MAckermann@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:noloader@gmail.com]
> > Sent: Friday, September 23, 2016 10:55 AM
> > To: Ackermann, Michael <MAckermann@bcbsm.com>
> > Cc: BITS Security <BITSSecurity@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 <
> MAckermann@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
>