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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 20 July 2017 17:21 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E8A3B12700F for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 10:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 F3yG4nijN4RA for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 10:21:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6351131D0A for <tls@ietf.org>; Thu, 20 Jul 2017 10:21:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CC927BE39; Thu, 20 Jul 2017 18:21:46 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSHaDvT_Mcfm; Thu, 20 Jul 2017 18:21:45 +0100 (IST)
Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34F9BBE38; Thu, 20 Jul 2017 18:21:45 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500571305; bh=QtJpE9HrmhmSF/Mqi6tlzjJ8zR/KSP4RQsr/r18hmCM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UGbjNsm75IWSVlmgWOV0G8IealFp4Fc19jZgZAiLpwCrzMQbaf/UMJZTaGV+yHqiE fyDNh7ylNXWf+Pcl1cHhQPnJhVWhw6ajT7YKg75JYbBmG9epP3DjAbLhSEowUZiSmZ ZQs9H93IIFUhxO0mhdeX7F+l1lEn2gTJ2Cdu6iJY=
To: Colm MacCárthaigh <colm@allcosts.net>
Cc: "Salz, Rich" <rsalz@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
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> <CAPt1N1kDjeWSXucZJmxNr9rpVOh=hZoXknWn+HzL7sOYTXc4mQ@mail.gmail.com> <CAAF6GDcCnf=O64bnVQXnNHXQAQGY3h5RSjDD0sEE=R1ruEzGcA@mail.gmail.com> <cec29b2f-0bac-0758-569d-d341ee81b842@cs.tcd.ie> <CAAF6GDfyTsn9uqxBhFiw0gUo76xtTCS8jhvKruGyFpFRoB=zOw@mail.gmail.com> <DM2PR21MB00915FC926FEE6F64324E62D8CA70@DM2PR21MB0091.namprd21.prod.outlook.com> <CAAF6GDfSk3z4WfGx5GQ_3YqUWcsF76cqG5HVvLEYxobr8CApTg@mail.gmail.com> <DM2PR21MB00910D605F561667F655D1698CA70@DM2PR21MB0091.namprd21.prod.outlook.com> <a5d8e3f6fdd24fae858ce5d1a4c3b36f@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDcX-Oxeb5iTeL_jWEtNEdWFQb9+SqSkspmTKVf5WZSwrg@mail.gmail.com> <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie> <CAAF6GDeFuRy0DN6w3FwmR_nh1G=YBi4+qiEcw0MfSRj4SUCbZQ@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <e181d7cb-9143-c8eb-7c64-e07e3bd6fffb@cs.tcd.ie>
Date: Thu, 20 Jul 2017 18:21:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAAF6GDeFuRy0DN6w3FwmR_nh1G=YBi4+qiEcw0MfSRj4SUCbZQ@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="mLgEUiT42qx0vPQnNIj8DISPFM6hoXq0L"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tqXlqDKZXfQoMgdkAWq1DnHXMVw>
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: Thu, 20 Jul 2017 17:21:51 -0000


On 20/07/17 18:08, Colm MacCárthaigh wrote:
> On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> 
>> On 20/07/17 17:43, Colm MacCárthaigh wrote:
>>> that's the term that people keep applying,
>>
>> That term was appropriate for draft-green as justified in [1]
>> That's disputed by some folks but it's the correct term.
>>
> 
> If you maintain that draft-green is Wiretapping, then that is also the
> correct term for what is happening today. Today, operators are using a
> static key, used on the endpoints they control, to decrypt traffic
> passively. The only difference is DH vs RSA, and I know you'll agree that's
> not material.
> 
> Claiming that current browsers "support" wiretapping is plain
>> odd to me and not that useful for the discussion but isn't a
>> TLS protocol issue as we don't currently have, and don't have
>> a WG proposal for a draft-green like wiretapping API as part
>> of the TLS WG set of RFCs.
>>
> 
> It is odd ... and I'm being deliberately provocative to get at the
> doublethink. It is impossible to consider this mode wiretapping and not
> claim the browsers support it today. Plainly, they do.

In what sense does a browser "support" a server leaking a private
key via some proprietary interface? That makes zero sense to me
and seems sheer hyperbole, as you said yourself. And not useful.

> 
> We don't live in an abstract theoretical world in which this is not already

More hyperbole is less useful.

> happening, and is not already possible. 

When using crypto in a network protocol, it is impossible to know
or not know that a peer is implementing crypto well or badly.

> It will also continue to be
> possible to MITM traffic, if you have the RSA key, and some dh-static
> opponents even advocate for this. I have seen no intellectually consistent
> explanation for why that is ok, 

I never said it was "ok." I said it wasn't part of the TLS RFCs.

The point here is to not specify mechanisms that enable wiretapping
to the extent that is feasible (you seem to assume that all uses
of crypto "support" wiretapping, since it's always possible for an
implementation to leak keys - that's gibberish IMO, but I'm using
the term in your sense in this paragraph).

> why that won't be abused by coercive
> authorities, 

It could be. It'd still be abuse IMO.

> and hence why it is not better to have something in between;

"something in between" is just nonsense sorry. Your strawman
proposition that we define all crypto as "supporting" wiretapping
being nonsense, means that so is that bogus pseudo-compromise.

But given that this aspect isn't really useful discussion, I
hope we can leave it there.

Cheers,
S.


> that gives providers what they claim to need, but not the coercers.


>