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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 06 December 2018 21:06 UTC

Return-Path: <dkg@fifthhorseman.net>
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 698A3130EDA for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 13:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK6BQxPKo_86 for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 13:06:05 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC9E130ED7 for <tls@ietf.org>; Thu, 6 Dec 2018 13:06:05 -0800 (PST)
Received: from fifthhorseman.net (41-139-152-102.safaricombusiness.co.ke [41.139.152.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 5CB9BF99A; Thu, 6 Dec 2018 16:05:51 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 16D4B2041D; Fri, 7 Dec 2018 00:04:53 +0300 (EAT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Andrei Popov <Andrei.Popov@microsoft.com>, "tls@ietf.org" <tls@ietf.org>
In-Reply-To: <SN6PR2101MB1055D37EB2DD393B9DB042238CA90@SN6PR2101MB1055.namprd21.prod.outlook.com>
References: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <20181202233553.GD15561@localhost> <CAHOTMV+vPkM-=Qsto-8-ipFuGsNKkH_U=BEY_mB=7CM7tto3Mw@mail.gmail.com> <38D10A65-B4EE-4E81-8EA4-D69514F7F47B@gmail.com> <51754d91-c00c-0cad-ecd6-8db74544d26a@cs.tcd.ie> <A7423BAF-398B-4BBE-81AC-364CE748D6B1@gmail.com> <9344c0e1-f484-2b4b-8594-1d29731f6b7a@cs.tcd.ie> <01429BF7-BF1D-4F1C-9E18-D796A5585E62@gmail.com> <2F72F9A9-1556-4F44-8BBA-4D4CDD1A310C@akamai.com> <cd138d5d-37be-acee-297c-011227e98b99@nomountain.net> <SN6PR2101MB1055D37EB2DD393B9DB042238CA90@SN6PR2101MB1055.namprd21.prod.outlook.com>
Date: Fri, 07 Dec 2018 00:04:50 +0300
Message-ID: <874lbqe58t.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aq9GHqMflIkD7fdzcKu9iIc327o>
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: Thu, 06 Dec 2018 21:06:06 -0000

On Thu 2018-12-06 02:10:06 +0000, Andrei Popov wrote:
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.

hm, thinking about this optimization approach, i would really like to
know what implementations are doing this.  It occurs to me that client
implementations as well as server implementations could be doing this
"for efficiency reasons".

If both sides do it, and two connections are established within the
window before the "ephemeral" keys are disposed of, then you could end
up in a scenario where you actually have a "Handshake Secret" and
"Master Secret" that are reused across a connection, and this would be
entirely observable by a passive monitor.

That leaves the only defense against direct key reuse for encryption on
the wire the entropy in:

 * ClientHello and ServerHello (for
   {client,server}_handshake_traffic_secret)

 * ClientHello and server Finished (for
   {client,server}_application_traffic_secret_0 and
   exporter_master_secret)

 * ClientHello and client Finished (for
   resumption_master_secret)

Seems like risky business... we're leaning heavily on HKDF-Expand-Label
to keep a passive observer from being able to identify how the actual
traffic keys across sessions are related to one another.  Or am i
missing something?  I'd love for someone to correct me here.

Maybe i'll add a section to the draft explicitly forbidding clients from
ever taking this "optimization" step as well.

      --dkg