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

Nico Williams <> Sun, 02 December 2018 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBF7F130DD0 for <>; Sun, 2 Dec 2018 15:36:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 n-e2Hd1vRuSx for <>; Sun, 2 Dec 2018 15:36:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEF0B130DBE for <>; Sun, 2 Dec 2018 15:36:02 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id C60CD123418; Sun, 2 Dec 2018 23:36:00 +0000 (UTC)
Received: from (unknown []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 6F4851232E9; Sun, 2 Dec 2018 23:36:00 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.16.2); Sun, 02 Dec 2018 23:36:00 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Whimsical-Average: 26dcb7447f6a7af9_1543793760625_1886971960
X-MC-Loop-Signature: 1543793760625:1465763227
X-MC-Ingress-Time: 1543793760624
Received: from (localhost []) by (Postfix) with ESMTP id 362C97F916; Sun, 2 Dec 2018 15:36:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=2vouw6nQVcdvap Ocvrnu1sKXhaQ=; b=BUDu7Ie+CifJHZhewXb9K8r4ItYHOEMCXK/OAWUubtxAfL /zQuA/URiDRwaZT+AzYRdGDlc8+sjolbuFe1Gn4/j4J0hUJOK3ClVDqnrgJhfmQA BxK/OMEdbQZsaJpft+pFkA35/5jQvsr2pC5Rg6/HowZBTZCBnFDhd7rwLyFH0=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id B4CD17F91E; Sun, 2 Dec 2018 15:35:56 -0800 (PST)
Date: Sun, 2 Dec 2018 17:35:54 -0600
X-DH-BACKEND: pdx1-sub0-mail-a26
From: Nico Williams <>
To: Tony Arcieri <>
Cc:, Crypto <>, "<>" <>
Message-ID: <20181202233553.GD15561@localhost>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedruddvledgkeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
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: Sun, 02 Dec 2018 23:36:05 -0000

On Sat, Dec 01, 2018 at 07:59:45AM -0800, Tony Arcieri wrote:
> This does not seem to address a problem which was brought up when the
> similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> system in possession of one of the non-ephemeral-ECDHE private keys,
> ostensibly for the purposes of passive traffic decryption, can arbitrarily
> resume decrypted sessions and therefore impersonate any observed clients.
> I'm not a fan of systems like this, but I believe for security reasons they
> should be designed in such a way that only the confidentiality of traffic
> is impacted, and a "visibility" system isn't able to leverage the decrypted
> traffic to resume decrypted sessions and thereby impersonate clients.

Any key escrow system will have this property.  Given the session keys
(or a way to recover them) you can resume decrypted sessions.

If I had to I would build a corporate TLS 1.3 session key escrow system
as follows:

 - use a keyed PRF/PRNG to generate the ephemeral DH keys, with two
   inputs, a secret key shared with the escrow third party, and a number
   generated randomly:

   edh_key = DH_key_gen(seed = PRF+(escrowed_key, r = getrandom()));

 - log to the escrow third party {connection ID, random} for each
   connection (the connection ID can be a handshake transcript hash).

   (it's even safe to log the random number r in the clear, as it alone
   is insufficient for recovering session keys)

This would preserve all the properties of TLS 1.3 and would work for any
other version of TLS with EDH too, and also for any other protocols that
use ephemeral key agreement (SSHv2, IKE, ...).

It's more work to integrate this than to use RSA key transport with
escrowed RSA key orchestration, but it's one-time work (do it for about
six or so open source implementations and you've got 90+% coverage).

I'm sure upstreams would accept this sort of contribution as it is
better for everyone outside corporate environments if we can just stop
the pressure to go back to RSA key transport.  It's also better for
corporate environments, as insiders are the largest threat there, so
forward security is still a plus even in corporate environments.