Re: [TLS] chairs - please shutdown wiretapping discussion...

Kyle Rose <krose@krose.org> Wed, 12 July 2017 14:18 UTC

Return-Path: <krose@krose.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 444DC1316A8 for <tls@ietfa.amsl.com>; Wed, 12 Jul 2017 07:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 nzwA4puXj9i6 for <tls@ietfa.amsl.com>; Wed, 12 Jul 2017 07:18:50 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C1A129B15 for <tls@ietf.org>; Wed, 12 Jul 2017 07:18:50 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id l21so10954055ywb.1 for <tls@ietf.org>; Wed, 12 Jul 2017 07:18:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Olwo/IlvNgJTneRKyboj25+EM6eLYPadMbVDk428lc=; b=Dz9QJkBeQGcCl4NRRf/+beav/GPmuDUkCtOEW38iJpt/kS4JLJmf2yzjCmm/tw9J0M Yt95dy/YO40/eMtpA5AzThYC2FA0VTI7IBhCTI1gH1oqmg3LGsQHCqYwVWWwaHxqFyHQ axyfLN6AqHi2i1/FXCb99VVftWPd607NvqnzY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/Olwo/IlvNgJTneRKyboj25+EM6eLYPadMbVDk428lc=; b=Wcn9JE5e85TFro3nPg9vc4EEQPA2+CbaoR+YmP9r5rmLUYHWhhoAnNADISwZ5tseyG NwYF8u7mRKUPF4rW7mIYjRWIOKq8TgUSFfYHGrtBxz8XyItIODtV39lOYrPVm4ngrsJi P9ROdU9ZPfMhBaAyPsrNksUCRxOY3P8gA5HGuSs9D0TfPVV2/VgkoUXZ4L/xIB22oJUz pzHZJGzY+MNsJqXB2wjxYRgDdUFRAsSGaGh1uSrM1heRmbXVQio2QrXvpJD27XF79fl4 Gmy4daL51sFvAPV2aiufjo4OvDv8HiWnpFMi/d+cV85oIlUq8ZM+zXff2twD92yP+U4Q 1ePg==
X-Gm-Message-State: AIVw113/5rvm6KeLb5Zaqh+uENBkVB6mq8jLQr02vHuuUmYVAx+UL0yX Bh3WfafoD3RXvJNhyf8RaCT9Rjc0bamTVbs=
X-Received: by 10.237.41.132 with SMTP id o4mr6445903qtd.242.1499869129183; Wed, 12 Jul 2017 07:18:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.128.194 with HTTP; Wed, 12 Jul 2017 07:18:47 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <E235BB49-8179-4F6B-A164-137BA27A3412@fugue.com>
References: <E9640B43-B3AD-48D7-910D-F284030B5466@nist.gov> <CY4PR14MB13688370E0544C9B84BB52A3D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <CY4PR14MB1368BA01881DD9495FE86DF0D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <d806a69c-af30-c963-a361-91075332a61b@cs.tcd.ie> <F87D7646-DC53-4EF8-A2D8-D0939A0FB351@vigilsec.com> <b9001044-83d7-805c-2a49-c2780401bbf8@cs.tcd.ie> <C4125902-CA3A-4EA8-989B-8B1CE41598FB@fugue.com> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <CAJU8_nWpzZY5-0B1d8D6ced1Us3N63DC92FMLbn+t4RyE=fLcw@mail.gmail.com> <E235BB49-8179-4F6B-A164-137BA27A3412@fugue.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 12 Jul 2017 10:18:47 -0400
Message-ID: <CAJU8_nVtFsSWu5odxgz+VUsjy9MS-Ji3moxTmc4A2rywF=FJpg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: IETF TLS <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c08f22ea7ac3505541f7e4f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yvDENS4P6sSkFUqYLTqRu-NZt9I>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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: Wed, 12 Jul 2017 14:18:52 -0000

On Wed, Jul 12, 2017 at 8:57 AM, Ted Lemon <mellon@fugue.com>; wrote:

> The problem is that in modern times we can't assume that collaboration is
> consensual, so the rules in RFC2804 aren't as applicable as they were.
>

Until someone comes up with a technical countermeasure for involuntary
collusion, the solution space is entirely political. This isn't nuclear
science, in which it was conceivable in the 1940's that consensus among the
entire community of nuclear physicists could have crippled the development
of the bomb: the IETF neither discussing nor publishing a document
describing a mechanism for session key sharing does not imply that a
government hell-bent on pervasive surveillance will be unable to force
something down the throats of site admins, because even the
not-entirely-broken ways of doing this are pretty obvious extensions to the
protocol.

We need to dispel the myth that mere inaction on our part will on its own
prevent implementation of these mechanisms, if for no other reason but to
redirect energy to the political arena where the pervasive monitoring
battles *are* actually fought.


> There's no way to have the consensual collaboration use case without
> enabling the non-consensual use case.   Anything we do that makes it easier
> to enable the non-consensual use case is a bad idea.   So in my mind RFC
> 7258 is more applicable here than RFC 2804.
>

No contest.


> The problem with arguing this on the basis of whether or not there is a
> non-wiretapping operational use case for this is that there *is* a
> legitimate non-wiretapping operational use case here.   As I understand it,
> the motivation for doing this is to be able to avoid deploying different
> pieces of DPI hardware differently in data centers.   That's a legitimate
> motivation.   The problem is that (IMHO) it's not a good enough reason to
> standardize this.
>
> I would much rather see people who have this operational use case continue
> to use TLS 1.2 until the custom DPI hardware that they are depending on is
> sufficiently obsolete that they are going to remove it anyway; at that
> point they can retool and switch to TLS 1.3 without needing support for
> static keys.   The advantage of this is that simply using TLS 1.2 signals
> to the client that the privacy protections of TLS 1.3 are not available, so
> you get the consensual aspect that Tim was arguing for without having to
> modify TLS 1.3.
>

Absolutely. Your recommendation (among others') is precisely why I am
opposed to censoring this (or any) discussion. We're not the protocol
police: while there is simply no way for us to prevent implementors from
doing misguided things, we can provide alternatives and recommendations
along with justifications for those judgments. But I see this discussion as
mostly limited to improving the practical security of actual users, not as
part of some larger war against wiretapping or pervasive surveillance. This
isn't that battle, and this is not where that battle will be fought if
governments decide they want those things.

Kyle