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

Colm MacCárthaigh <> Wed, 19 July 2017 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB86F13167D for <>; Wed, 19 Jul 2017 10:45:15 -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 c_C0qk_lgyN8 for <>; Wed, 19 Jul 2017 10:45:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91D64129461 for <>; Wed, 19 Jul 2017 10:45:14 -0700 (PDT)
Received: by with SMTP id v193so3513839ywg.2 for <>; Wed, 19 Jul 2017 10:45:14 -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=nqhRfmZWMd3HdyTI3Z5GMGeQg0RtadqyRw24qf6K3/Y=; b=TUI9Po+5u0uYtXZhcFcysE+gRZtJhmCUkqDoInYrpwb3rvy4//KCwSyEeGttARGApM JuWRrrZs83UuexEji0T3pr+VFkcYRzcGfdNNkvHXTkpkC+I3ia6dNHjmJS5TuhxF5Pbz d4HGpDAzMjwMwt3BLPPc9enUFoWw1ctYjymnFchjq/Ws4fIpHcpJHs3aAuDakDpKpqOT 0bgSwvBDooTCRb76gjqxZdFYAnruipKY1M96orvzNTOhMEhH5XG7xFV7ZtgLlbyhGfS2 yffbWDkZdQajHFCBIwCPxP7lxymGHeiCbKPnmLbh/Iq9I0OcU8qeQk0Twtd5utj48Bqc WPlA==
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=nqhRfmZWMd3HdyTI3Z5GMGeQg0RtadqyRw24qf6K3/Y=; b=rsIRaMImmo8zCJ+frkNjh3okP0mCXEayeo4ibzvm2zkBPpVdx6xa0RzGPHU+unOKmG eUQ8XJkTFEH8aKmw7TPxzEnP6yERyXxpO9naTApRNN1vjf9vL96IUHSNsfkvDFHXcn/M f4g8tdqexCAm9KYJI84o5tmHGoJS+1AUHRoX11gU8MlLyRhz8UmxDzTJk7of9nKPDoek kNTcoxFEGKKi7Y3V8KCnZSfaeM/MsaHfcwBs8sXSQ6NqNGBAvct0NoT6B5Aj2ndDQdoN ts4dVOACrYtujw7HXYadJ6KHM/EZTMmBXvDblmMQ+JLmFei5e3o9kithBp2fseNZzlSA jIfw==
X-Gm-Message-State: AIVw111sMiVJICchGLinKqAYNXYGPuwsqEvGLhTRz1u/gdRrsNdCGVs0 hS5nitBGHY9tpUTm0sTWv9VXDqDHkvpu
X-Received: by with SMTP id u129mr809425ywc.171.1500486313610; Wed, 19 Jul 2017 10:45:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jul 2017 10:45:13 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Date: Wed, 19 Jul 2017 10:45:13 -0700
Message-ID: <>
To: Ted Lemon <>
Cc: Stephen Farrell <>, "<>" <>
Content-Type: multipart/alternative; boundary="94eb2c0a93c0b6e0410554af310c"
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 17:45:16 -0000

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