Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Russ Housley <> Fri, 07 July 2017 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CBFA1316DE for <>; Fri, 7 Jul 2017 09:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HnX8OZwZCyi3 for <>; Fri, 7 Jul 2017 09:35:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63FEF1316D9 for <>; Fri, 7 Jul 2017 09:35:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B971A30053F for <>; Fri, 7 Jul 2017 12:35:22 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id 0uNA7TeT19rf for <>; Fri, 7 Jul 2017 12:35:19 -0400 (EDT)
Received: from a860b60074bd.home ( []) by (Postfix) with ESMTPSA id 2642E30023A; Fri, 7 Jul 2017 12:35:19 -0400 (EDT)
From: Russ Housley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B50A222-3C0A-41E0-AE25-0D18691EDAC0"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 7 Jul 2017 12:35:18 -0400
In-Reply-To: <>
Cc: Matthew Green <>, IETF TLS <>
To: Richard Barnes <>
References: <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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: Fri, 07 Jul 2017 16:35:26 -0000


> Without taking a position on whether this group should take on this work, a couple of questions about alternative approaches (sorry if these have been answered before):
> 1. It seems like the requirement here is that the DH private key be *predictable* by the monitoring box based on some static configuration.  That is, it seems like you could have keys that are predictable to the monitoring device, but still vary over time, something like setting the private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom). Without having done much analysis, this seems more conservative than making things entirely static. Is there a reason to prefer the purely static approach besides simplicity?

Please see Section 6 of the draft.  The non-ephemeral DH keys MUST have a validity period.  The keys are expected to change over time.

> 2. You could avoid changing how the DH works altogether by simply exporting the DH private key, encrypted with a key shared with the monitoring device, in a server extension.  (Not in EncryptedExtensions, obviously.)  This would also have the benefit of explicitly signaling when such monitoring is in use.  The only real challenge here is that the client would have to offer the extension in order for the server to be able to send it, which I expect things like browsers would be unlikely to do.  However, given that the target of this draft seems to be intra-data-center TLS, perhaps this is a workable requirement?

In most common deployment case, the load balancer at the edge of the enterprise datacenter will terminate the TLS session and start a new one.  The TLS session that protects the traffic on the public Internet works exactly as described in draft-ietf-tls-tls13.  The non-ephemeral DH keys are associated only with sessions that are inside the enterprise datacenter.  So, you are right, no browser will be at either end of any of these TLS sessions.  There is no change to the way that the protocol makes use of the DH key.  The drft-green, the server need to look in a table to choose a valid non-ephemeral DH key.  In your proposal, the server need to wrap the ephemeral DH private key in a key-enceyption key.  Both solutions require the distribution of some key (either the non-ephemenral DH key or the key-encryption key) to the parties that are authorized to see the traffic.


> I don't believe the WG should adopt this as it goes
> against rfc2804 and encourages bad behaviour. We
> ought not be helping to normalise broken crypto. I'm
> happy to repeat that at the mic in Prague but would
> be even happier if this draft were not discussed
> there - these attempts to weaken security have IMO
> already taken up too much time and too many cycles.

Repeating from above, the non-ephemeral DH keys are associated only with sessions that are inside the enterprise datacenter.  In some industries, there are regulatory requirements that cannot be met without access to the plaintext.  Without some authorized access mechanism, the enterprise will be forced to use plaintext within the datacenter.  That seems like a worse alternative to me.


> On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green < <>> wrote:
> The need for enterprise datacenters to access TLS 1.3 plaintext for security and operational requirements has been under discussion since shortly before the Seoul IETF meeting. This draft provides current thinking about the way to facilitate plain text access based on the use of static (EC)DH keys on the servers. These keys have a lifetime; they get replaced on a regular schedule. A key manager in the datacenter generates and distributes these keys.  The Asymmetric Key Package [RFC5958] format is used to transfer and load the keys wherever they are authorized for use.
> We have asked for a few minutes to talk about this draft in the TLS WG session at the upcoming Prague IETF. Please take a look so we can have a productive discussion.  Of course, we're eager to start that discussion on the mail list in advance of the meeting.
> The draft can be found here:
> <>
> Thanks for your attention,
> Matt, Ralph, Paul, Steve, and Russ