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

Ion Larranaga Azcue <> Sat, 24 March 2018 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78BFB126D3F for <>; Sat, 24 Mar 2018 12:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qb-bA84UMkz7 for <>; Sat, 24 Mar 2018 12:37:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C441C1242F5 for <>; Sat, 24 Mar 2018 12:37:38 -0700 (PDT)
From: Ion Larranaga Azcue <>
To: Jim Reid <>, Dan Brown <>
CC: "" <>
Thread-Topic: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
Thread-Index: AQHTw6eOMnwc4T8JRDihe6zQIW66uA==
Date: Sat, 24 Mar 2018 19:37:34 +0000
Message-ID: <>
Accept-Language: es-ES, pt-PT, en-US
Content-Language: es-ES
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Mar 2018 19:37:41 -0000

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 <>; en nombre de Jim Reid <>;
Enviado: sábado, 24 de marzo de 2018 16:56
Para: Dan Brown
Asunto: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

> On 19 Mar 2018, at 15:18, Dan Brown <>; 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.