Re: [TLS] Breaking into TLS to protect customers

Benjamin Kaduk <kaduk@mit.edu> Mon, 19 March 2018 16:30 UTC

Return-Path: <kaduk@mit.edu>
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 3C2EB126E01 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 09:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 TYYH3d6QeMw4 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 09:30:09 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA401242EA for <tls@ietf.org>; Mon, 19 Mar 2018 09:30:08 -0700 (PDT)
X-AuditID: 12074425-e37ff70000007e6e-8a-5aafe58d4a24
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 04.42.32366.E85EFAA5; Mon, 19 Mar 2018 12:30:07 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w2JGU1Rx006798; Mon, 19 Mar 2018 12:30:02 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2JGTv0D001755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Mar 2018 12:29:59 -0400
Date: Mon, 19 Mar 2018 11:29:57 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180319162957.GM55745@kduck.kaduk.org>
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> <87y3iottae.fsf@fifthhorseman.net> <883E9392-9163-4523-AB95-35738E27CE5D@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <883E9392-9163-4523-AB95-35738E27CE5D@gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixG6nrtv/dH2Uwd5GXovW7s9MFp/OdzFa LD32gcmB2eNsdzurx85Zd9k9liz5yRTAHMVlk5Kak1mWWqRvl8CVcWvmJtaCZqGKczd2sDUw HuDrYuTkkBAwkZj24BlLFyMXh5DAYiaJTcs3QzkbGSWab/2Hcq4ySezYvJoNpIVFQFVi2qPX 7CA2m4CKREP3ZWYQW0RASeLwla9gNrOAn8Surd1MILawgKXEo/0zwOp5gdZt3vMBaug2Jonp l/czQSQEJU7OfMIC0awu8WfeJaBBHEC2tMTyfxwQYXmJ5q2zweZzCthKPH2/EKxcVEBZYm/f IfYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0 EyM42F1UdzDO+et1iFGAg1GJh1fjzvooIdbEsuLK3EOMkhxMSqK8+ROBQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4n15ZFyXEm5JYWZValA+TkuZgURLn9TDRjhISSE8sSc1OTS1ILYLJynBw KEnwejwBGipYlJqeWpGWmVOCkGbi4AQZzgM0XB2khre4IDG3ODMdIn+KUZfjxovXbcxCLHn5 ealS4rzOIEUCIEUZpXlwc0BJSiJ7f80rRnGgt4R5r4FU8QATHNykV0BLmICW+CxdA7KkJBEh JdXAqPyReWeoosT14Kt/9zafSdvaUJTDlGj2rT54ntGLo0Gr3ma8im9tzSvmufThckPQPDcB iyr5K9v8gt9sS9kRbXS2qapMu6720eXHmpuWF/xtqa2TMv+xbqa7zuz6SF7LgKv2ExsVIgM8 DV8d4XK/dMbjUZzq99nMLS9NPPjL7p4p3e3ifOCIEktxRqKhFnNRcSIAEh3GDy0DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wU8plSCoWKzwAKt7YrEwhIZwKEI>
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 16:30:17 -0000

On Mon, Mar 19, 2018 at 01:23:30PM +0000, Yoav Nir wrote:
> Hi, Daniel
> 
> Inline...
> 
> > On 19 Mar 2018, at 7:32, Daniel Kahn Gillmor <dkg@fifthhorseman.net>; wrote:
> > 
> > 
> > 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?
> 
> I see it a little differently. Your computer or my computer, both of which are not configured to opt-in, should not be on such networks. In the corporate world, there could be a production network that enforces this and has access to corporate resources. There will usually also be a “guest” network with unfiltered connectivity, but no access to internal databases. This is where visitors go, but also where employee phones connect.
> 
> Of course the government of Elbonia might require all networks to have this feature, and then you’ll have to decide if you want to configure your laptop to opt-in.  I would prefer to stay off-line while I’m in Elbonia in that case.
> 
> > 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?
> 
> This is for hosts using network owned by the same entity that owns the hosts. When such hosts communicate outside this network, it’s for the leg of the connection that is within this network. I don’t see any use for it across an adversarial network.  If you trust it enough to give it your keys, it’s not adversarial.

If the network is actually trusted, then there is no need for
transport encryption at all.  So, whether due to real risk or risk
perceived by compliance regimes, the network must be considered to
potentially be adversarial.  Perhaps this could be rephrased as "the
intended network is operated by a trusted entity", but is the
network authenticated?  With an attacker potentially in play, is the
network compromised?  It's hardly a home run to blithely claim that
the network is trusted, without further exposition.

-Ben