Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 15 July 2017 06:26 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 A109812EC37 for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 23:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ItrdYZyOoG7X for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 23:26:46 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id ADDE612EB69 for <tls@ietf.org>; Fri, 14 Jul 2017 23:26:46 -0700 (PDT)
Received: from fifthhorseman.net (38.200.broadband6.iol.cz [88.101.200.38]) by che.mayfirst.org (Postfix) with ESMTPSA id 6AA67F999; Sat, 15 Jul 2017 02:26:44 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 4F712202F8; Sat, 15 Jul 2017 08:26:39 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Russ Housley <housley@vigilsec.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
In-Reply-To: <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <CAJU8_nXBFkpncFDy4QFnd6hFpC7oOZn-F1-EuBC2vk3Y6QKq3A@mail.gmail.com> <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie> <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com>
Date: Sat, 15 Jul 2017 08:26:35 +0200
Message-ID: <87k23arzac.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/QXY8KS-b4_Y2mVS0RBid8sgeI4w>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 15 Jul 2017 06:26:48 -0000

On Fri 2017-07-07 16:04:20 -0400, Russ Housley wrote:

> In some industries, there are regulatory requirements that cannot be
> met without access to the plaintext.

This is surely true, but it's not clear to me that any regulator
requires access to the plaintext *from direct network capture*.

Could you point to an example of any regulation that requires plaintext
from network capture specifically?

There are many non-network-based ways that plaintext can be produced as
required by the regulated endpoints, without introducing a standardized
mechanism that increases the attack surface of widespread
implementations on the public Internet.

Why should we privilege network capture (e.g. retrospectively
decryptable pcap dumps) as a means of meeting regulatory requirements
when:

 (a) other means of meeting regulatory requirements exist, and

 (b) we know that network capture is widely used adversarially by the
     kinds of attackers that TLS is explicitly intended to defend
     against?

       --dkg