Re: [TLS] TLS interception technologies that can be used with TLS 1.3

R du Toit <> Thu, 15 March 2018 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E4F5126C89 for <>; Thu, 15 Mar 2018 15:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.018
X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UfYdVwOqjQe1 for <>; Thu, 15 Mar 2018 15:24:31 -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 616441241FC for <>; Thu, 15 Mar 2018 15:24:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1521152665; s=zoho;;; h=Date:Subject:From:To:Message-ID:References:In-Reply-To:Mime-version:Content-type; l=19405; bh=PPhScqLJON9NszpiYPjPSNiBqu8XzyXnOE8dp4sw0Jo=; b=LEM/fsvJzmZrkmMXUs98b6xIBU4vF2Ht3Ndp+gc/ZO6708sWd3wF4Px1n3HMOUXM 7z10WAU5aAT7iXMX0ybfwQQzSIPxvUM46ViEDUSi/lkJyuU9ndin3VYnI51dIhOT3BN gXN3ull+Ms1by7JghXD9zQNTTrJuCB/ZpD+8T4ik=
Received: from [] ( []) by with SMTPS id 1521152665614584.6202951705372; Thu, 15 Mar 2018 15:24:25 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.b.0.180311
Date: Thu, 15 Mar 2018 18:24:23 -0400
From: R du Toit <>
To: "" <>
Message-ID: <>
Thread-Topic: [TLS] TLS interception technologies that can be used with TLS 1.3
References: <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3603983065_743742537"
X-ZohoMailClient: External
X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D
Archived-At: <>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3
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: Thu, 15 Mar 2018 22:24:35 -0000

(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.




From: TLS <>; on behalf of Hubert Kario <>;
Date: Thursday, March 15, 2018 at 7:38 AM
To: <>;
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...


> On 15 Mar 2018, at 2:16, Watson Ladd <>; 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 mailing list





Hubert Kario

Senior Quality Engineer, QE BaseOS Security team


Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic_______________________________________________

TLS mailing list