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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 06 December 2018 23:30 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 D2943130F26 for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 15:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 kxkdRvqL5zNt for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 15:30:20 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4A3131217 for <tls@ietf.org>; Thu, 6 Dec 2018 15:30:20 -0800 (PST)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 3308FA6519 for <tls@ietf.org>; Thu, 6 Dec 2018 18:30:19 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <SN6PR2101MB105593ED12E9110068F9808F8CA90@SN6PR2101MB1055.namprd21.prod.outlook.com>
Date: Thu, 6 Dec 2018 18:30:18 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: IETF TLS WG <tls@ietf.org>
Message-Id: <FC507668-1B08-4FF9-9B3C-7AD1B806FFBE@dukhovni.org>
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>
To: IETF TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JRAeDHNSV4a5EIykK5SdtWUltcI>
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:30:26 -0000

> On Dec 6, 2018, at 4:08 PM, Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>; wrote:
> 
> Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing connections to "enterprise TLS" servers would probably qualify as "essential circumstances", at least to some operators.

I don't think the TLS WG or IETF can win this skirmish.  If some
operators are set on session recording, they'll find a way, and
the more obstacles they have to overcome the more likely they are
to compromise security along the way.

So while clients should not do anything special to support this,
and the protocol should not change to adapt to the use-case, it
might in fact be more productive to help the operators who need
this arrive at an approach that minimizes risk.  Explicitly
trying to defeat what they're sure to do anyway does look like
a wise approach to me.

The operators could, for example, derive the (EC)DH private key
from an HMAC of the client and server random with a secret
key shared with the wiretap device.  The client would never
know, and the (EC)DH key would not look any different to an
outside observer.

The best we can probably do is publicize the risks, so that
auditors are well aware of them and can highlight poor designs,
and hope that some operators will decide they can do without
such intercepts, or will use an approach that preserves as
much security as possible.

-- 
	Viktor.