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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 06 December 2018 23:58 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 B0F9D13122D for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 15:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5IqAyPALcu8Q for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 15:58:21 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0B1130F26 for <tls@ietf.org>; Thu, 6 Dec 2018 15:58:21 -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 86B91F99A; Thu, 6 Dec 2018 18:58:20 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 1D9692041D; Fri, 7 Dec 2018 02:45:16 +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: <SN6PR2101MB105593ED12E9110068F9808F8CA90@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> <87d0qee736.fsf@fifthhorseman.net> <SN6PR2101MB105593ED12E9110068F9808F8CA90@SN6PR2101MB1055.namprd21.prod.outlook.com>
Date: Fri, 07 Dec 2018 02:45:12 +0300
Message-ID: <87mupicj93.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/683Mr8pWpqhuFlwjjMRY27ovjLc>
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 23:58:24 -0000

On Thu 2018-12-06 21:08:00 +0000, Andrei Popov wrote:
> In a specific quick test that I did, there was no significant perf
> impact with key reuse time > 1 sec. And I could probably get it down
> to sub-seconds on my HW. But HW specs differ between TLS servers; our
> current "ephemeral" key lifetime is a generous 30 sec., mainly because
> we saw no reason to push for a lower key lifetime.

Is this on both client side and server side?  That is, does SChannel as
a client also use an "ephemeral" key lifetime of a generous 30 seconds?

> "Truly malicious" is perhaps an overstatement for this easy workaround explicitly permitted by the "Enterprise TLS" spec:
> "In some essential circumstances, the visibility information field may be omitted."

The ETSI "Middlebox Security Protocol" explicitly aims to drop Annex A.
They've said that they *want* visibility and that is an explicit goal.

Surely the purpose of visibility is to ensure that both parties involved
are running the significantly weaker eTLS, and not TLS.  Opting for
visibility while expecting clients to not do anything with the knowledge
gained doesn't make much sense to me.

       --dkg