Re: [TLS] Breaking into TLS to protect customers

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 19 March 2018 09:42 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 3B94C127023 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 02:42:41 -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 NZJIUqgA9NDD for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 02:42:40 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C565112E046 for <tls@ietf.org>; Mon, 19 Mar 2018 02:42:23 -0700 (PDT)
Received: from fifthhorseman.net (dhcp-8362.meeting.ietf.org [31.133.131.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 9EA17F99A; Mon, 19 Mar 2018 05:42:22 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 22E962039D; Mon, 19 Mar 2018 07:32:13 +0000 (GMT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Yoav Nir <ynir.ietf@gmail.com>, Ion Larranaga Azcue <ilarra@s21sec.com>
Cc: "tls@ietf.org" <tls@ietf.org>
In-Reply-To: <6888195D-1AD6-45B1-8F77-AFA088CFF78A@gmail.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com> <6888195D-1AD6-45B1-8F77-AFA088CFF78A@gmail.com>
Date: Mon, 19 Mar 2018 07:32:09 +0000
Message-ID: <87y3iottae.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/w7QQhOkLJMa9VACdugZWc5wd32I>
Subject: Re: [TLS] Breaking into TLS to protect customers
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: Mon, 19 Mar 2018 09:42:41 -0000

On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote:
>> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue <ilarra@s21sec.com> wrote:
>> 
>> I fail to see how the current draft can be used to provide visibility
>> to an IPS system in order to detect bots that are inside the bank…
>> 
>> On the one hand, the bot would never opt-in for visibility if it’s
>> trying to exfiltrate data…
>
> The presumption is that any legitimate application would opt-in, so
> the IPS blocks any TLS connection that does not opt in.

Thanks for clarifying the bigger picture here, Yoav.

So if this technology were deployed on a network where not all parties
are mutually trusting, it would offer network users a choice between
surveillance by the network on the one hand (opt-in) and censorship on
the other (opt-out and be blocked).  Is that right?

Designing mechanism for the Internet that allows/facilitates/encourages
the network operator to force this choice on the user seems problematic.
Why do we want this for a protocol like TLS that is intended to be used
across potentially adversarial networks?

datacenter operators who want access to the cleartext passing through
machines they already control already have mechanisms at their disposal
to do this (whether they can do so at scale safely without exposing
their customers' data to further risks is maybe an open question,
regardless of mechanism).

Mechanisms that increase "visibility" of the cleartext run counter to
the goals of TLS as an end-to-end two-party secure communications
protocol.

Regards,

     --dkg