Re: [TLS] ETSI releases standards for enterprise security and data centre management

Daniel Kahn Gillmor <> Thu, 06 December 2018 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DDBD131186 for <>; Thu, 6 Dec 2018 12:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rhwUSzBcOTN3 for <>; Thu, 6 Dec 2018 12:33:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D5E5130F7E for <>; Thu, 6 Dec 2018 12:33:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DDA77F99B; Thu, 6 Dec 2018 15:33:18 -0500 (EST)
Received: by (Postfix, from userid 1000) id 664AE20381; Thu, 6 Dec 2018 23:25:04 +0300 (EAT)
From: Daniel Kahn Gillmor <>
To: Andrei Popov <>, "tls\" <>
In-Reply-To: <>
References: <> <> <20181202233553.GD15561@localhost> <> <> <> <> <> <> <> <> <>
Date: Thu, 06 Dec 2018 23:25:01 +0300
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
X-Mailman-Version: 2.1.29
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, 06 Dec 2018 20:33:22 -0000

Hi Andrei--

On Thu 2018-12-06 02:10:06 +0000, Andrei Popov wrote:
> I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will cost servers some perf:
>    "Given the concerns in Section 2 and the necessary client mitigations
>    in the subsections above, servers need to avoid giving the appearance
>    of using non-ephemeral DH.  Servers MUST NOT reuse ephemeral DH
>    shares."
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.

interesting, i'd love to see more details on those tests if you can
share them.  What kind of load are we talking about?  Which server

The cost here is in the fixed-base operation, iiuc, which is the
cheapest part of the handshake -- DH share reuse allows you to skip this
one step per handshake (or rather, to amortize the one step across
multiple handshakes).

You mention a cutoff of 1 second.  If the amortization is spread across,
say, all handshakes within 2 seconds, is the performance impact still

If the draft's server guidance were to be amended to suggest avoiding DH
reuse for more than 2 seconds, and the guidance for clients to track
added a buffer of 2 seconds before rejection, would that satisfy your
concerns about performance under load?

> Also, won't the "enterprise TLS" server just create a bunch of static
> DH shares and send different ones at different times, thereby avoiding
> detection by most clients?

I don't think that the intent of the ETSI spec is to encourage
non-visible use.  They've specifically stated visibility to clients as a
primary goal, and acknoweldged that "Annex A" servers would be in
violation of their own goals.

So it's conceivable that truly malicious servers would do this, of
course, but they might also just publish the master secret on twitter
too, and the client wouldn't know how to detect that inband either.  But
for the misbehavior that we *can* detect in-band, a responsible client
should be aware of it and avoid it, right?