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

Colm MacCárthaigh <colm@allcosts.net> Wed, 19 July 2017 18:01 UTC

Return-Path: <colm@allcosts.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 4A528131AAF for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 11:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 K6wr9k4eNmuI for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 5BB02131B76 for <tls@ietf.org>; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id a12so3641650ywh.3 for <tls@ietf.org>; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8Q/Q0k44w4nu8iCxPg9IrhTnydqYaBT59xvlulgUq4M=; b=Kl3+JRBlpkno6HAPDof/7xla8qh2omNaZl/cLqvPFKIHQIZWcpIiN65bhPhrK+6NJl lYXHC/Hvd5w5eJ7wY6B9S635ZsS6QRmTMFys+vMiD3NGyr7pqpOv2lNn07fPWRV4Wqdp T7jQC2QJzvmbfzkHhlQXw1u/pCHOUV/h+gU6ZRkgAzP+C1UtIlSpqtV8fKKMn0XZY6yM J2Mw15Puwty6Hou48YLoZpQJVyHhNuRk3SR0iO0utNJ94fA9RheDKlSjLPj2UpSqBXAR gy6savHQinT5N161N6STuVzWthLjoRxuRfzew8aGuIDiPI4+MZPuAcx4RFQKzARSpM65 C1ZQ==
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=8Q/Q0k44w4nu8iCxPg9IrhTnydqYaBT59xvlulgUq4M=; b=MprQAswXPMbn7JPKeB4VW3UyjYncFky7j4FMgbrh1bm/P1FR4yRx3qK3k3k2MHOtys evIlkXb6+CW4dM1Y4nAbMmTxVFgIGXOfrUiVj1cB6jDQVAji0Leo+As+iJmXuwnepdEP vIQx9yKY4vkg4tZ+NXpKXSfw04efHetIiwZTG5pGI0ikYnJr71sgxGwB+JynhhD3rpLM s9/Tu9ILE28qIJj0b+T3JbmhWQuQ6Hefmq+JsPtR4LvU6SFxPCrhIdo/8+/4ie9KvTCI tv/e/dz8hQac6UQdJbvLH7to3iC7P6K+TAcEsOOCdxOVqL95eZ7wk4R0HK4fS13hgISA mZug==
X-Gm-Message-State: AIVw110LcHd4mCg/6xE56/zVjcVkhr+kmsVKPvMb9iZNte/RhrbCaoew Cs6juMa2lOFHrLoUTPbNF5kfoe0AQCAf
X-Received: by 10.129.178.133 with SMTP id q127mr817722ywh.49.1500487264437; Wed, 19 Jul 2017 11:01:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 11:01:03 -0700 (PDT)
In-Reply-To: <CAPt1N1=XDBEh4meKLpnZRugEuq4E6HGHUagCpOpEaKM6L819Ug@mail.gmail.com>
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> <CAPt1N1=XDBEh4meKLpnZRugEuq4E6HGHUagCpOpEaKM6L819Ug@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Date: Wed, 19 Jul 2017 11:01:03 -0700
Message-ID: <CAAF6GDdaG4VuPVrStmzDfgbsG6m2eDOdjKWK4=2uLny32EnTTA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c146c3c63812e0554af6a24"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OlF5t04xqpwHGvosiBtE80i9Hh8>
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 18:01:07 -0000

On Wed, Jul 19, 2017 at 10:55 AM, Ted Lemon <mellon@fugue.com> wrote:

> Sorry, the more I think about how to do this in a way that doesn't make
> things worse, the less faith I have that it is possible.   But if you know
> of a way to do it, I certainly don't oppose you doing it.   I'm not an
> expert: the fact that I don't see how to do it doesn't mean it can't be
> done.
>

I think it was Nick who had the idea of adding a message to the TLS
transcript that encrypts the PMS or session key under a public key. This
had some advantages:

* Static-DH can be banned and clients can check for changing DH parameters.
* The technique would be signaled and opt-in to clients; they can terminate
the connection if they don't want it. Clients could insist on being
configured to support it, not support it in incognito mode, etc.
* The PMS/key could be encrypted under a different key than the key pair
used to authenticate the server; this means that the servers needn't have a
key that can decrypt these transcripts. It can be kept offline. It also
means that the investigation team needn't have access to the servers
certificate private key. Much better all-round.
* Still can work with tcpdump/wireshark etc, but not very useful to three
letter agencies, etc.


>
> On Wed, Jul 19, 2017 at 7:45 PM, Colm MacCárthaigh <colm@allcosts.net>
> wrote:
>
>>
>>
>> On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <mellon@fugue.com> wrote:
>>
>>> 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.
>>>
>>
>> I find this a very bizarre outcome that works against our collective
>> goals. If there is no mechanism at all, then it is quite likely that
>> organizations will use static-DH or stay on TLS1.2. Those are bad options,
>> in my opinion, because there's no signaling or opt-in to the client. We can
>> do much better than that.  Client opt-ins are far from academic. For
>> example, browser's incognito modes may refuse to support such sessions, if
>> they knew what was going on.
>>
>> It's also bad if organizations end up deploying static-DH and that means
>> we can't do things like checking for changing DH parameters.
>>
>> It seems like we would be rejecting a good opportunity to make what the
>> network operators want work in a better and more secure way, while making
>> it harder for passive observers and coercive authorities, to use the same
>> mechanism for other purposes. What do we gain? beyond a hollow moral
>> victory.
>>
>> --
>> Colm
>>
>
>


-- 
Colm