Re: [TLS] datacenter TLS decryption as a three-party protocol

Ted Lemon <mellon@fugue.com> Wed, 19 July 2017 17:39 UTC

Return-Path: <mellon@fugue.com>
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 DE335131A50 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 10:39:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 TBynnbtaDV6p for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 10:39:25 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 497FF12EBF4 for <tls@ietf.org>; Wed, 19 Jul 2017 10:39:25 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id e199so2640082pfh.2 for <tls@ietf.org>; Wed, 19 Jul 2017 10:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VzG3RB8OCMxbBEoQt/nhmHCepe+Svaw2kWIJmsqHduA=; b=VYJtbPO2XH36vvwKEQIP/9F1z3xaoYgc+yDSf/oTqD+z04FYVxrhJpR5HL47gJA2ZC htuI7w4Mgfp3MlRH6h4xLtsEVQCgT61badrWAaAEHDxEZoCwFrLJv2ZTFv/qW59bfRsG hX7GORVhcP02jtkofhYGARzCaFJa/psZ4+Cop0Tn+pLjxzYI9pBqEE0fFzBlu0PQd7fD 0ygm74yPK5Cl7Kttl70BOmF6vBLUCx2RRYfw2Vr8mBTwir30XOrO+SZLDaPGRXysmzl7 HixovIvOsbgRF6d2JBYPygzTI/QuDS7k9uKsKRLvBJU4+7L5qofPKelaefNSEpa54fzh inhw==
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=VzG3RB8OCMxbBEoQt/nhmHCepe+Svaw2kWIJmsqHduA=; b=RAs53r/J/uPbpjPMIcl8/+ECk1o39zlTG1deZKejuH1LrLIHs3KuvaxESdkiTjzOjk h6hiuhj/0VMCpKEECYkiEqViqZS01afk/5PD8lDnHGwOQJfnttkE7EoIRLS2YzK1xvTl 9iJHyxScboaO9AzV2nh9NBwTqUPYpB6hFIAk29E2eWLtJcMuGEor2Ei+MOG2YtLixo/T HiXJ40Siyt/9p5xbGhrBt+tIux5w3Vflf9hWycCAzduA1kuMB1RKsxhQD0QqTsZsb04v D+t1cANR9SQvxVFqbEi+Ao5xLZNznN29oHoZPfcyWEYcjAcP1E1Ry8hA60aCtcYu//O1 033w==
X-Gm-Message-State: AIVw112/LScqvpmBCS948houHNp1OXHcvB0toE+YwacimY52oqCDRDs1 D2mDFf1gq8qforMph2txWFWOvFJdkbf/
X-Received: by 10.99.44.66 with SMTP id s63mr890907pgs.302.1500485964894; Wed, 19 Jul 2017 10:39:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 10:38:44 -0700 (PDT)
In-Reply-To: <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 19 Jul 2017 19:38:44 +0200
Message-ID: <CAPt1N1kDjeWSXucZJmxNr9rpVOh=hZoXknWn+HzL7sOYTXc4mQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e48bcedabce0554af1c76"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/z6nO7NaSV2brA2trONF9tY84jkQ>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
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, 19 Jul 2017 17:39:28 -0000

The problem is that the actual solution to this problem is to accept that
you aren't going to be able to decrypt the streams, and then figure out
what to do instead.   Which is work the proponents of not doing that are
not interested in doing, understandably, and which is also not the work of
this working group.

I'm skeptical that there is a way for this working group to solve the
proposed problem, but if there is, it involves figuring out a way to do
this that doesn't make it easy to MiTM *my* connections, or, say, those of
activists in dangerous places.

On Wed, Jul 19, 2017 at 7:33 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

>
>
> On 19/07/17 17:58, Benjamin Kaduk wrote:
> > On 07/19/2017 11:49 AM, Stephen Farrell wrote:
> >>
> >> On 19/07/17 14:09, Benjamin Kaduk wrote:
> >>> As Stephen noted in his presentation, a lot of the proposals for
> passive
> >>> decryption can be seen as trying to turn TLS from a two-party protocol
> >>> into a three-party protocol.  Which is probably the right way to think
> >>> about it, even when all (three) parties are within the same
> >>> administrative domain.
> >>>
> >>> Stephen also said something about it being hard to shoehorn a
> >>> three-party protocol into the API for a two party protocol.  But
> >>> depending on the specifics, maybe it's not so bad.  For example, if the
> >>> only semantics you need are a new API for "this is the list of third
> >>> parties I authorize to wiretap this connection", the scope seems fairly
> >>> limited.
> >> I would question the size of the set of applications for which the
> >> semantics of such a list/interface could make sense. For example,
> >> asking a person if they're ok with some random IPv6 address spying
> >> on a TLS session makes zero sense for example.
> >>
> >
> > Sure, some random IPv6 address makes no sense, and is not
> > cryptographically bound to anything.
> > On the other hand, "this (semi-)static DH key is one currently used by
> > my enterprise's network monitoring system, and is allowed to read my
> > traffic" seems closer to what is being asked for.
>
> I don't know how that kind of identifier can be made meaningful
> for almost any application where the identifier is not already
> meaningful, and in many such cases I would guess there are
> already hop-by-hop behaviours where TLS is not e2e for the
> application layer (MTAs etc.) But sure, someone could do the
> work to describe some applications that might have a need for
> a multiparty security protocol like that I guess. As I said,
> my guess is that the size of that set of applications is small.
>
> >
> > As has been said downthread, the recommendation is not "you should
> > always use this thing", it's "you should do TLS 1.3 without backdoors,
> > but if you really need to, this is a way to do so with known and limited
> > properties".
>
> I can see why people might consider that some kind of compromise
> that's less bad, but I think searching for "less bad" is not at all
> the right approach. I don't mean that we oughtn't investigate
> possible scenarios, but searching for a compromise is not in itself
> a good goal here.
>
> Cheers,
> S.
>
> >
> > -Ben
> >
> > -Ben
> >
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>