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

Nico Williams <nico@cryptonector.com> Tue, 04 December 2018 15:48 UTC

Return-Path: <nico@cryptonector.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 ACD6E130E85 for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 07:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 whe9VLYWqUOA for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 07:48:22 -0800 (PST)
Received: from bird.maple.relay.mailchannels.net (bird.maple.relay.mailchannels.net [23.83.214.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CBA130E7E for <tls@ietf.org>; Tue, 4 Dec 2018 07:48:21 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 68BD05C3427; Tue, 4 Dec 2018 15:48:17 +0000 (UTC)
Received: from pdx1-sub0-mail-a26.g.dreamhost.com (unknown [100.96.19.74]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 12AB35C3DA0; Tue, 4 Dec 2018 15:48:17 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 04 Dec 2018 15:48:17 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Eyes-Scare: 474f66824588c38c_1543938497240_2113590519
X-MC-Loop-Signature: 1543938497240:3885549034
X-MC-Ingress-Time: 1543938497240
Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id 8682C7FB04; Tue, 4 Dec 2018 07:48:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Nugp7Y0GSOrJym 86IBstHOLQsKA=; b=bpGz6lzyEI8IinFFRGU6dtOVws5LDBlvW1VUVf4A0aeYhR tImfTc0WmvlMZPF98oPqYvCCjMxuM5MfFEBiKEpJ9/agVuuK2lfy0dNWV/3HlHXX YUdNf2WDy+tR8XxjplZmhRr9+IYlmBtwx7cx+lViu9TWbUFgWdkKpYk+5kJFw=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 8D4687FB0B; Tue, 4 Dec 2018 07:48:14 -0800 (PST)
Date: Tue, 4 Dec 2018 09:48:12 -0600
X-DH-BACKEND: pdx1-sub0-mail-a26
From: Nico Williams <nico@cryptonector.com>
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20181204154811.GK15561@localhost>
References: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <20181202233553.GD15561@localhost> <CACykbs0ZESBKYzF9=VxbmrLXkqZs843MpQsjiMYK10Q3BLf85Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACykbs0ZESBKYzF9=VxbmrLXkqZs843MpQsjiMYK10Q3BLf85Q@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudeffedgkedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EC4qilUi-NPNbjAzSD4HztcsY28>
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 15:48:24 -0000

On Tue, Dec 04, 2018 at 04:34:08PM +0100, Jonathan Hoyland wrote:
> Is it necessarily true that any key escrow system must allow resumptions?
> 
> Just to play devil's advocate, consider defining a new cipher suite that
> appended a MAC to each message before applying one of the other cipher
> suites.
> If the MAC is keyed with a key not derived from the master secret, but from
> some other value shared between the client and server, but not the
> middlebox, then the middlebox would be able to read all* the traffic, but
> would not be able to successfully resume the session.

This MAC key would also have to be involved in the session resumption
PSK, but yes.  You don't even need this extra MAC past the handshake,
you just need an extra key not known to the escrow agent for use in the
session resumption PSK.  (The extra MAC on every record would impose too
much overhead.)

> *The middlebox would not be able to verify the tag, so technically it can't
> check /everything/, but it would be able to read the data on the channel
> without being able to modify it.

Oh sure, if you're willing to do such violence to TLS, then yes, it can
be done.

However, a constraint here is that an escrow design can't really require
client-side modifications without the IETF approving of it and the
client implementations accepting the change.

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.

Nico
--