IETF Logo Mail Archive

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

Tony Arcieri <bascule@gmail.com> Tue, 04 December 2018 16:18 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFAB130EA8 for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 08:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cnec0ewDDfDn for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 08:18:57 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71D0130E5F for <tls@ietf.org>; Tue, 4 Dec 2018 08:18:56 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id n8so11822207otl.6 for <tls@ietf.org>; Tue, 04 Dec 2018 08:18:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <20181202233553.GD15561@localhost>
In-Reply-To: <20181202233553.GD15561@localhost>
From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 04 Dec 2018 08:18:44 -0800
Message-ID: <CAHOTMV+vPkM-=Qsto-8-ipFuGsNKkH_U=BEY_mB=7CM7tto3Mw@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Dmitry Belyavsky <beldmit@gmail.com>, Crypto <cryptography@metzdowd.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000497abc057c349fb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VEYjuAp-fogdemBeoFhj8tRYodc>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2018 16:18:59 -0000

On Sun, Dec 2, 2018 at 3:36 PM Nico Williams <nico@cryptonector.com> 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
resumption.

 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

v2.23.0 | Report a Bug | By Email