(We have many related discussions currently.. this seemed like the most appropriate thread for my response)
Enterprises are asking for out-of-band TLS decryption, per use-cases outlined in draft-fenter-tls-decryption-00 (and others before that). The current proposal for said out-of-band TLS decryption is draft-rhrd-tls-tls13-visibility-01, which requires opt-in from the TLS server by way of a new “TLS Visibility” extension. If draft-fenter has all the requirements and draft-rhd is supposed to be the solution then the implication is that every TLS endpoint in the enterprise datacenter (and possibly outside the datacenter if those TLS endpoints do not enter via some TLS termination node) must support the proposed TLS extension. I am also assuming that some enterprise key management solution product is already deployed in the datacenter, and that those products remotely manage the full lifecycle of the TLS endpoint RSA keys and certificates. Summary: all endpoints must change, and all endpoints are managed. So, why are we not discussing dynamic out-of-band TLS session secret sharing or TLS secret escrow as solutions? (I call it secrets instead of keys because TLS 1.3 gives us the ability to share different parts of the session secret hierarchy, e.g. sharing “client/server_application_traffic_secret0” instead of sharing “Master Secret”). The secrets would be shared by the actual TLS endpoints, so it requires no changes to TLS. I do understand that it would introduce new connectivity requirements for datacenter TLS nodes, but that is why I have the paragraph above where I list my assumptions: those nodes would have to change anyway and those nodes are remotely managed.. --Roelof From: TLS <tls-boun...@ietf.org> on behalf of Hubert Kario <hka...@redhat.com> Date: Thursday, March 15, 2018 at 7:38 AM To: <tls@ietf.org> Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3 On Thursday, 15 March 2018 05:51:31 CET Yoav Nir wrote: At the risk of stating the obvious, it’s because server owners want to use the same OpenSSL, NSS, SChannel, or whatever you call the Java library that everybody else uses. They’re all widely used, actively maintained, and essentially free. None of these libraries support any of this functionality. huh? Sure, it is not nicely packaged in to allow integration with 3rd party systems, and sometimes disabled by default, but it's hardly missing... https://github.com/openssl/openssl/pull/1646 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format https://bugs.chromium.org/p/chromium/issues/detail?id=393477 > On 15 Mar 2018, at 2:16, Watson Ladd <watsonbl...@gmail.com> wrote: > > One can either use a static DH share, save the ephemerals on the > servers and export them, or log all the data on the servers. > > These options don't require any change to the wire protocol: they just > require vendors supporting them. Why don't they meet the needs cited? > > Sincerely, > Watson > > _______________________________________________ > 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 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic_______________________________________________ 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
