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

Steve Fenter <> Mon, 26 March 2018 11:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87B4312711E for <>; Mon, 26 Mar 2018 04:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3rQBH_xREcF5 for <>; Mon, 26 Mar 2018 04:29:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7944120713 for <>; Mon, 26 Mar 2018 04:29:56 -0700 (PDT)
Received: by with SMTP id t12so5374048pgp.13 for <>; Mon, 26 Mar 2018 04:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=jLEVp+zWVtQpsuyHpGIfeqPFMF3XDsU1arrQxls4meM=; b=XI7yhMWZv/H8bESwlR7rYa4MHyt72949hCDuXDLRdP3BmF1C5xAv5yP/AOzeFIzgb7 YWUWLS1PfBzn20GwnfGsCi8pPib6J89mDOBCBC6QAxEhxf5Tgyfk71SbNcRY1GYbYVL/ TV0el9lcgj0X8tRREQ1Rbc3VHODtv43OPVknQpvlOMNOA1zDcqDF1qNB8B1aBfH/QKUI 5TJb0xbYaBEqwazuBfpgbJKyEo7yxoi7i0Un5Zg5fdoWWQYtLDjvlIz+q4CsYXmPIBwi QCYBwQVhu3gwPNXwAY1PAmg9TRbITzbVDz/CaR2QE8NcnJ06OuYqzyyQsQ3F+MmixROk omBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=jLEVp+zWVtQpsuyHpGIfeqPFMF3XDsU1arrQxls4meM=; b=UQmMECwDLMZeIXXiw5wRVy/Gqgl42Jr9vnIT0wa7xLvX9KJy5xpbDSHJZ30/Bd16UX 88mhIoP03e7ELYPnhLqueUWDuWmATpXeBuIgMSEMoz+pImxonYICeLeKaZFzHFWLRsZP XT44urQDqSNjTCXNE0hGlzGKTdOOaGGY79Sapz13CPOrzGixWZQ9yp74AyFI11uwU2S8 7TINyMFhpzHu1nU7RkvE+6B4E3ipyPjxc9d2zT3u2FYSJAGDVdMzQ30dnXjW0bxyJG7Y zwu4BYdrnOjfeyI3DKZ3sN0oU7+jMBoyygH1ka6FpUb7PvQ5t9kbOin3VQ7k+f6UQnCx qqGA==
X-Gm-Message-State: AElRT7GgHjh4mzwNM0gDUQqbR0A5oPfRnbjzJyl+Y+5vTV5rmdNd45sM HSU6ARRK3kF39pSICLirmk8=
X-Google-Smtp-Source: AG47ELutZlmjTSXTMtJXUDjQuJRkl3rCbFLRsOu1Dv2O9LlrTDGVeHkDJ8fUE0QjqZomYxrCmR79OQ==
X-Received: by with SMTP id j87mr20453983pfj.59.1522063796465; Mon, 26 Mar 2018 04:29:56 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id c189sm25892305pfg.72.2018. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Mar 2018 04:29:55 -0700 (PDT)
References: <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <>
Cc: Jim Reid <>, Dan Brown <>, "" <>
X-Mailer: iPad Mail (11D201)
From: Steve Fenter <>
Date: Mon, 26 Mar 2018 12:29:54 +0100
To: Ion Larranaga Azcue <>
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: Mon, 26 Mar 2018 11:29:58 -0000

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 <>; 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 <>; en nombre de Jim Reid <>;
> Enviado: sábado, 24 de marzo de 2018 16:56
> Para: Dan Brown
> Cc:
> 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.
> _______________________________________________
> TLS mailing list