Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

To clarify for anyone who has confusion on the enterprise TLS visibility use case, I think enterprises need to be able to do out-of-band decryption anywhere in the network that they own.  It would be reasonable to terminate TLS on the enterprise's Internet connection, both inbound TLS and outbound TLS, as well as on business to business connections.  We could run standard TLS 1.3 on these external connections, and then run our modified TLS on the inside.

We also have internal browsers as well as other internal clients going to internal TLS servers, and these need deep packet inspection as well.  Terminating TLS on the internal WAN head-end 
is less attractive, because there are significant sites outside of the data center that need troubleshooting and network security monitoring.  For example, a large metropolitan area may have many office buildings with thousands of users as well as local servers.  There can also be thousands of branch-type offices.  We don't want to be blind to these large areas of our enterprise network.  I think "scoping the solution to the data center" is the wrong way to phrase this, but rather it should be scoping to the internal enterprise network, owned and operated by the enterprise.

Also, while there are some enterprises who terminate TLS coming in from the Internet and then run clear text on the inside, there are others who run new TLS sessions internally.  There is a need for packet decryption and inspection at many layers of this internal TLS network.

Steve Fenter

> On Mar 24, 2018, at 7:37 PM, Ion Larranaga Azcue <ilarra@s21sec.com> wrote:
> 
> I recognize I may lack context, because I have only seen Steve Fenter's slides, but apart from it not reaching consensus, the scenario it presents (user connecting to online banking service) seems to be visibility of connections from the internet to internal servers. 
> 
> I think that not even visibility proponents agree between them, as sometimes they seem to require "server-to-server" visibility within the data center while periodically use cases appear (such as the one you mention) where traffic to be decrypted goes from internet to the internal network (or even viceversa). I'm starting to understand someone who some months ago said this looked like playing "whack-a-mole".
> 
> Besides, from what I understand from Steve Fenter's proposal (I may be wrong because I have seen only the slides) , they seem to go for non-visible TLS 1.3 connections from the client to the external layers of the network, and visible TLS 1.3 connections within their internal network. This would match the idea of "visibility only within the datacenter" but in my opinion it requires a finalization of the external tunnel and creation of a new internal one. At that point you obviously have the clear text and you could move your monitor tasks to that point.
> 
> So maybe it's because the presentation is obsolete or because I lack context but... no, I don't think those specific slides are a valid example today.
> 
> ________________________________________
> De: TLS <tls-bounces@ietf.org> en nombre de Jim Reid <jim@rfc1035.com>
> Enviado: sábado, 24 de marzo de 2018 16:56
> Para: Dan Brown
> Cc: tls@ietf.org
> Asunto: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
> 
>> On 19 Mar 2018, at 15:18, Dan Brown <danibrown@blackberry.com> wrote:
>> 
>> PS: I never directly worked on enterprise security (usually, I just think about the math of basic crypto primitives), but I don't recall hearing about such a "visibility" feature in the enterprise security work of colleagues (whom I do _not_ speak for), e.g. one system used forward-secure ECMQV to establish a connection between smartphones and the enterprise network.
> 
> Hearsay anecdote is not evidence. :-)
> 
> There are use cases in enterprise networks, notably in banking and finance. Some of these were presented to the TLS WG. [See Steve Fenter’s presentation at IETF97.] However the WG did not reach consensus on adopting the relevant drafts as work items.
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls