Re: [TLS] Breaking into TLS to protect customers

Benjamin Kaduk <kaduk@mit.edu> Thu, 22 March 2018 10:03 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 3B188126D05 for <tls@ietfa.amsl.com>; Thu, 22 Mar 2018 03:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 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] 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 Qq0qWVK0uQj0 for <tls@ietfa.amsl.com>; Thu, 22 Mar 2018 03:03:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 6763E126C89 for <tls@ietf.org>; Thu, 22 Mar 2018 03:03:51 -0700 (PDT)
X-AuditID: 1209190e-b09ff700000016fa-16-5ab37f8659bd
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 32.8C.05882.68F73BA5; Thu, 22 Mar 2018 06:03:50 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w2MA3ntn029751; Thu, 22 Mar 2018 06:03:49 -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 w2MA3jsU002927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2018 06:03:47 -0400
Date: Thu, 22 Mar 2018 05:03:45 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= <colm@allcosts.net>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180322100344.GP55745@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> <CAAF6GDeAOKtCF5BhfyG6wEd5L-mevKeuDMM1AmgdGKyfuEyzdQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAF6GDeAOKtCF5BhfyG6wEd5L-mevKeuDMM1AmgdGKyfuEyzdQ@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixCmqrdtWvznK4N8mCYsvTbsZLVq7PzNZ fDrfxejA7HF90W5Wj7Pd7aweS5b8ZApgjuKySUnNySxLLdK3S+DKONvbxl6wX6vi4pfvbA2M PxW7GDk5JARMJA5v2MrexcjFISSwmEni/c75bBDORkaJlRf2MkI4V5kknlw7xQLSwiKgKrH5 9momEJtNQEWiofsyM4gtImAjca6zGSzOLOAnsWtrN5gtLGAp8Wj/DHYQmxdo3d7FrVDrTjFJ PFz1gxEiIShxcuYTFohmdYk/8y4BDeUAsqUllv/jgAjLSzRvnQ22i1MgUOLS9wVg80UFlCX2 9h1in8AoOAvJpFlIJs1CmDQLyaQFjCyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJT SjcxgoNdkm8H46QG70OMAhyMSjy8GTmbooRYE8uKK3MPMUpyMCmJ8n56ARTiS8pPqcxILM6I LyrNSS0+xCjBwawkwntIc3OUEG9KYmVValE+TEqag0VJnNfdRDtKSCA9sSQ1OzW1ILUIJivD waEkwbu4DqhRsCg1PbUiLTOnBCHNxMEJMpwHaHgaSA1vcUFibnFmOkT+FKMxx5+HL9uYOW68 eN3GLMSSl5+XKiXOqwRSKgBSmlGaBzcNlLAksvfXvGIUB3pOmHcdSBUPMNnBzXsFtIoJaFX2 zA0gq0oSEVJSDYzyt8r39/Nsin2o+2Sak/G96Hc3mXf2HJWNePM+/tzl//X7rmur395dV7b+ /5xbU19zzG1xXLEpQcJg5aoJCbYt5+tvNR3RCbhw443j+VNe8fkVwSEVExbuM3ZQjF7us0Fg quURiV37NBKOOdgsOc6lxHem9vuWJZNnzrnfvPf4i/x11yT+nJZjU2Ipzkg01GIuKk4EANi6 YVczAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/txikjcr37s_7UVaI_s0_Q3ZpJTE>
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: Thu, 22 Mar 2018 10:03:54 -0000

[Apparently this was stuck in my 'drafts' folder; sorry if it has
since become stale...]

On Mon, Mar 19, 2018 at 07:20:04AM -0700, Colm MacCárthaigh wrote:
> It's true that breaking open cleartext runs counter to the mission of
> end-to-end TLS, but it also seems like operators are going to do it if they
> can. Whether by staying on plain RSA, using static-DH, MITM through
> installing a private trusted CA, or exporting session secrets, they can
> certainly do it.  I worry that we'll lose a good opportunity to improve the
> security and transparency of things by turning our nose up at that.
> 
> Here's a straw-man suggestion:

The straw man is indeed made of straw, but some observations
regardless...

> Suppose we took on a draft that adds a new optional handshake message. The
> message could go immediately before FINISHED, in either direction (or
> both), and contain an encrypted version of the soon-to-be-session-key.  For
> back-compat: it could be encrypted with RSA, or whatever else the endpoints
> want to support. This is basically what STEK encrypted tickets look like
> today with TLS1.2 anyway, though usually with symmetric encryption, so it's
> not that wild a departure.
> 
> Obviously this breaks forward secrecy, and allows passive tapping and
> session hi-jacking, but then that's the point. But I think there are some
> security advantages too:
> 
> 1/ By making the functionality part of the handshake transcript, it is
> unforgeably evident to both sides that it is happening. The proponents of
> this functionality claim that everything is opt-in, but this gives some
> cryptographic teeth to it.

It's not entirely clear that this scheme is forced into the
handshake, e.g., if the server collaborates with the network to drop
the new message, the server will not include it in the transcript
and the client will never see it, so the client would not
necessarily know about it.

But there are other ways to modify the key schedule that would
require both parties' consent (and potentially preconfiguration).
The most obvious ones would not technically be TLS anymore, but
would be very close; one could do this sort of thing with or without
a network-visible signal that it is in use, provided that both
endpoints agree that it is to be used.  For server-to-server, this
may be tolerable.


> 2/ clients and browsers could easily consider such sessions insecure by
> default. This would mean that adopters would have to deploy configurations
> and mechanisms to enable this functionality, similar to - but beyond - how
> private root CAs can be inserted.
> 
> Wouldn't those be good properties to have? Compared to servers secretly
> exporting transcripts or session keys, or just having a private root CA
> installed which breaks all sorts of certificate verification
> infrastructure?
> 
> I think the existence of a "standard" here could also serve to encourage
> providers to do things the more transparent way, and create less likelihood
> of a mass-market of products that could also be used for more surreptitious
> tapping.

Right, the claim has been made that a standard is useful so that
multiple vendors' products can interoperate within a single
enterprise.

-Ben

> 
> On Mon, Mar 19, 2018 at 12:32 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net
> > wrote:
> 
> > 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 mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> 
> 
> -- 
> Colm

> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls