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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 15 July 2017 11:24 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 71384131B10 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 04:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zZY8Jfh72POF for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 04:24:13 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 98C6D131471 for <tls@ietf.org>; Sat, 15 Jul 2017 04:24:13 -0700 (PDT)
Received: from fifthhorseman.net (dhcp-88bf.meeting.ietf.org [31.133.136.191]) by che.mayfirst.org (Postfix) with ESMTPSA id CBC34F99D; Sat, 15 Jul 2017 07:23:41 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id CA6AC20D76; Sat, 15 Jul 2017 13:23:38 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Dobbins\, Roland" <rdobbins@arbor.net>
Cc: Russ Housley <housley@vigilsec.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
In-Reply-To: <D37DF005-4C6E-4EA8-9D9D-6016A04DF69E@arbor.net>
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> <87k23arzac.fsf@fifthhorseman.net> <D37DF005-4C6E-4EA8-9D9D-6016A04DF69E@arbor.net>
Date: Sat, 15 Jul 2017 13:23:35 +0200
Message-ID: <871spirljc.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/Lk1D3Tl9V1vL7-148YoCR_TlcCQ>
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 11:24:14 -0000

On Sat 2017-07-15 07:42:58 +0000, Dobbins, Roland wrote:
>> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor <dkg@fifthhorseman.net>; wrote:
>> 
>> Could you point to an example of any regulation that requires plaintext
>> from network capture specifically?
>
> It often isn't feasible to obtain the plaintext any other way in a
> given circumstance.
>
> Not to mention the security & troubleshooting applications which
> require insight into the cryptostream on the wire.

I asked for examples of regulations that specifically require plaintext
from the network.

This e-mail contains no such example, just an assertion that it's
technically easier/simpler to do network capture for some deployments.
i believe this assertion, btw, so you don't need to argue it further.
Whether it justifies a loss of security is a separate question.

If anyone has a specific example of a regulation that mandates network
capture, i'd like to know about it.

If there are no such examples, and we plan to continue to discuss this
draft, i'd appreciate it if folks could take the "regulators require it"
argument off of the table, and we can focus on the actual technical
merits and risks of the proposal directly.

Regards,

    --dkg