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

Tony Arcieri <> Tue, 04 December 2018 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FFAB130EA8 for <>; Tue, 4 Dec 2018 08:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cnec0ewDDfDn for <>; Tue, 4 Dec 2018 08:18:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D71D0130E5F for <>; Tue, 4 Dec 2018 08:18:56 -0800 (PST)
Received: by with SMTP id n8so11822207otl.6 for <>; Tue, 04 Dec 2018 08:18:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FM45HhJffBwK/70ZC2nqYRzyRqF4PMyzMzXRKF2aMbA=; b=kTGQmrGqC69tCUw+UtLXR6ocpVC0/dstIx8AwxsbEOKOwIiZS2MTlODIHooVEosLPV VeOKONqV+kzBNrveXdXCt/btfj9l9aQAxsvoM42NpFj9dkXWYDmuGFH5yInSNsOULavs Ma6tK8uAY00qsxOHgHM/t61oMF0udBvh1UjHPDfr4a/QeqSCTJgOwCZh6IYUFiKrIt8Z UcSe9IFdPMRtYTHeYnmL4V5IGP305x+BY1iADwpGJY6AYI8XcRQn62PnXj2T+KHM84eS eU+ounxLmoosLuVBvWgdw3mkLHQKiC5lYfqmk3ZoRDmKGz7tEQj+bUNlae6LeU5RS7KT CqTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FM45HhJffBwK/70ZC2nqYRzyRqF4PMyzMzXRKF2aMbA=; b=nxwuSRoUlHgiFtq0YhuPngINv7bI7p3DjMWDB47GQSGFjfoi913j7g5E131734sMT5 59RUs7wnQGe8HTUdOyafpwET6UCjIpLEJc1W+Fztf3VmWmp7cNK4FyfMILErNnx/9Zru TW8v6jGhonBDzld9RVLiE2rcl9QXsVMguUAE5zWKm2+TbX3tMl7QI5kBnzELA25qEz8X MscvCpEqG0CuzCzgFLu0SCr+lxyn1TLOo1DUmU8kDRuEOT8RBEKNmYIplGobPrdLidt+ 2Z/w7+QwBvxo+zpw6MLaJz3F3UJQW95nKT8rXffRmlT4s0L6w7WqcUIqQxjPlZS/Isby vqWw==
X-Gm-Message-State: AA+aEWYGwY8Of7iYHS26nc2fh08zR537k1zf9+wl3lVvsYWLYCDz+N2f VJf2sclZYu3qYyh++hfjU5hGLgxPuOQSr9BhpkTVAJho
X-Google-Smtp-Source: AFSGD/UPsUvcOUYJEKV9n3mBQY8XVqIKBJDtvrc2ghXAmUReJOyUtH8484W6ve3ylDtIFV7nCFRf16vNewFcsJI0dGM=
X-Received: by 2002:a9d:1d43:: with SMTP id m61mr10749160otm.170.1543940336087; Tue, 04 Dec 2018 08:18:56 -0800 (PST)
MIME-Version: 1.0
References: <> <> <20181202233553.GD15561@localhost>
In-Reply-To: <20181202233553.GD15561@localhost>
From: Tony Arcieri <>
Date: Tue, 4 Dec 2018 08:18:44 -0800
Message-ID: <>
To: Nico Williams <>
Cc: Dmitry Belyavsky <>, Crypto <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000497abc057c349fb5"
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: Tue, 04 Dec 2018 16:18:59 -0000

On Sun, Dec 2, 2018 at 3:36 PM Nico Williams <> wrote:

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

Wouldn't escrowing only the client/server application traffic secrets
(instead of keys higher in the schedule) avoid this problem? These keys
would permit the one capability "visibility" appliance vendors allege to
care about: traffic decryption, without permitting others like session

 The most obvious escrow design requiring no changes to the clients is to
> use a static eDH key on the server-side.  The next most obvious such
> design is to have the server talk to the escrow agent.

It seems like with an out-of-band escrow agent, the traffic secrets could
be escrowed with no changes to TLS.

Tony Arcieri