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
- [TLS] Breaking into TLS to protect customers Salz, Rich
- Re: [TLS] Breaking into TLS to protect customers Artyom Gavrichenkov
- Re: [TLS] Breaking into TLS to protect customers Yoav Nir
- Re: [TLS] Breaking into TLS to protect customers nalini elkins
- Re: [TLS] Breaking into TLS to protect customers Ion Larranaga Azcue
- Re: [TLS] Breaking into TLS to protect customers Salz, Rich
- Re: [TLS] Breaking into TLS to protect customers Kathleen Moriarty
- Re: [TLS] Breaking into TLS to protect customers Carl Mehner
- Re: [TLS] Breaking into TLS to protect customers Kathleen Moriarty
- Re: [TLS] Breaking into TLS to protect customers Ion Larranaga Azcue
- Re: [TLS] Breaking into TLS to protect customers Yoav Nir
- Re: [TLS] Breaking into TLS to protect customers Roland Zink
- Re: [TLS] Breaking into TLS to protect customers Ackermann, Michael
- Re: [TLS] Breaking into TLS to protect customers Darin Pettis
- Re: [TLS] Breaking into TLS to protect customers Eric Mill
- Re: [TLS] Breaking into TLS to protect customers Matthew Ford
- Re: [TLS] Breaking into TLS to protect customers Daniel Kahn Gillmor
- Re: [TLS] Breaking into TLS to protect customers Joseph Lorenzo Hall
- Re: [TLS] Breaking into TLS to protect customers Yoav Nir
- Re: [TLS] Breaking into TLS to protect customers Colm MacCárthaigh
- Re: [TLS] Breaking into TLS to protect customers R du Toit
- Re: [TLS] Breaking into TLS to protect customers Ryan Sleevi
- Re: [TLS] Breaking into TLS to protect customers Benjamin Kaduk
- Re: [TLS] Breaking into TLS to protect customers Benjamin Kaduk
- Re: [TLS] Breaking into TLS to protect customers Salz, Rich
- Re: [TLS] Breaking into TLS to protect customers Eric Mill
- Re: [TLS] Breaking into TLS to protect customers Benjamin Kaduk