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

Colm MacCárthaigh <> Wed, 19 July 2017 18:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A528131AAF for <>; Wed, 19 Jul 2017 11:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K6wr9k4eNmuI for <>; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BB02131B76 for <>; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
Received: by with SMTP id a12so3641650ywh.3 for <>; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id q127mr817722ywh.49.1500487264437; Wed, 19 Jul 2017 11:01:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jul 2017 11:01:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Date: Wed, 19 Jul 2017 11:01:03 -0700
Message-ID: <>
To: Ted Lemon <>
Cc: Stephen Farrell <>, "<>" <>
Content-Type: multipart/alternative; boundary="94eb2c146c3c63812e0554af6a24"
Archived-At: <>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jul 2017 18:01:07 -0000

On Wed, Jul 19, 2017 at 10:55 AM, Ted Lemon <> 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 <>
> wrote:
>> On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <> 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