Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Eric Mill <> Sun, 09 July 2017 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A08512700F for <>; Sun, 9 Jul 2017 12:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=GQnYs+K4; dkim=neutral reason="invalid (public key: not available)" header.b=2CuajNfw
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0AOeFqXnLnfn for <>; Sun, 9 Jul 2017 12:16:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F78112ECCE for <>; Sun, 9 Jul 2017 12:16:48 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 3E14D9F016 for <>; Sun, 9 Jul 2017 15:16:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=3eNzk+av+DWg5S8ArHq3KlgVsGI=; b=GQnYs+ K4DQKY669iqBN0q9YLubZJS9W8yoHGCRFnHGKY8C4K3MPUJvH0hglz6QRQEcwxMP X6yiK72NsQuVQ11+NAHLO8SZ+uBXDhI+dM2PxGIByF1mAeBHm4fLMHxk2qzs6qkH 1QP6NoKh4+WhJn0lh+5aKUnbc3f2GxOrhjIMU=
Received: from (unknown []) by (Postfix) with ESMTP id 33B7C9F015 for <>; Sun, 9 Jul 2017 15:16:45 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6816F9F012 for <>; Sun, 9 Jul 2017 15:16:44 -0400 (EDT)
Received: by with SMTP id x125so28695634ywa.0 for <>; Sun, 09 Jul 2017 12:16:44 -0700 (PDT)
X-Gm-Message-State: AIVw111RIqybWhYrtvIAZS3htjCbKVm6i6qM7PYSgkvHjVDj5XFK/SAC uTCNGhe4haa1XUuyXRi9eQ3LdJ7M9g==
X-Received: by with SMTP id h5mr10073963ywb.51.1499627803727; Sun, 09 Jul 2017 12:16:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 9 Jul 2017 12:16:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Eric Mill <>
Date: Sun, 9 Jul 2017 15:16:02 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Cc: Watson Ladd <>, "" <>
Content-Type: multipart/alternative; boundary="001a114d8b388966e50553e74e7a"
X-Pobox-Relay-ID: 254B31C6-64DB-11E7-8605-EFB41968708C-82875391!
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=3eNzk+av+DWg5S8ArHq3KlgVsGI=; b=2CuajNfw3zLelUnc1dUJIspWBsLLYaaQCARbKAwHQ6JJ9xJLS/V+o1dUU9Iw5U1R6F90PQSzEogwTeWbQs2SGuk+fph0UbBBwwmQeNDxkJnS5+1Y3p2C5no5yrgP5blLI5RviP8qNZzXNDGecS4xXSSdo7nvBdLBxXuiK/GPse4=
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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: Sun, 09 Jul 2017 19:16:51 -0000

On Sun, Jul 9, 2017 at 2:04 AM, Colm MacCárthaigh <> wrote:

> On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd <> wrote:
>> > They also don’t want to install TLS proxies all over the place.  That’s
>> a
>> > large extra expense for them.
>> Nginx exists. What's the blocker?
> Here's how these networks work today:
> * Key servers are configured to use RSA KX, no DH.
> * In some cases, all outbound (e.g. internet) connectivity is also proxied
> via such a server. Clients are made to trust a private CA for this purpose.
> * All data is not necessarily logged or stored somewhere, and almost
> certainly not in the plain, as that would increase over-all risk.
> * Admins use port-mirrors and tools like tcpdump to investigate/scan
> suspicious flows from time to time, or as part of a targeted investigation.
> Occasionally it might also be used for debugging. The RSA keys can be used
> to render the connections plain on demand.
> * That doesn't mean that the RSA private keys are readily available, they
> are often very tightly controlled.
> Migrating to proxies would:
> * Be a very big operational change. Gotta get nginx on all of the boxes,
> is that even possible?

That's an oversimplification - proxying traffic should require addition of
points in the middle, but shouldn't (always) require modification of the
source and destination points.

But yes, it would be a big operational change. I don't think the folks
arguing that proxies can handle this are suggesting it's trivial to migrate
in this direction.

> * Completely change the access mechanisms, invalidate almost all of the
> operational controls.

Why wouldn't these be improvements? (More below.)

> * Probably more than double the basic compute costs associated with
> encryption.

Perhaps, but also probably more than doubles the cost to attackers, by
granting forward secret properties to internal traffic and by removing the
number of places where keys exist that are capable of decrypting this data.

* Create more sensitive environments where plaintext is floating around.

I don't see how that follows. In a previous message, Jacob Hoffman-Andrews
included a great description of why it should reduce the amount of access
to sensitive keys that can produce plaintext:

I would also point out that retrospectively decrypting pcaps asks TLS to do
double duty: as at-rest encryption in addition to transit encryption. If,
instead, each TLS server shares a copy of its plaintext via a TLS
connection to an encrypted storage service, the enterprise gets much better
security properties. Not only does it retain forward secrecy for
in-datacenter traffic, it can control the keys for at-rest data much more
tightly. Instead of every TLS frontend having the keys for retrospective
decryption, those keys can be limited to auditors or security team members.

> That doesn't mean that these vendors/operators are owed a solution, or an
> easy-to-insert more-or-less-compatible-with-today mechanism. But it does
> help assess whether they are really likely to adopt TLS1.3 to begin with.

That's quite fair. However, what's so far been unstated is that it's
plausible for regulatory pressure to eventually build to push regulated
enterprises towards TLS 1.3 and away from 1.2.

It's also quite plausible that regulatory pressure could eventually build
to push agencies to use encrypted traffic with forward secret properties
within their data centers, for the same reasons that it's unacceptable
today to send plaintext around.

This WG is responsible for making the strongest protocol possible, and it's
up to the rest of the world how to use it. TLS 1.3 looks likely to be
extremely widely used on the public internet. If enterprises end up staying
behind on TLS 1.2 inside their networks, or making their own non-standard
alternative, because they can't summon the will to get away from
network-based monitoring, they're likely to face costs for doing that
eventually, whether regulatory or just in the ongoing overhead of creating
and maintaining non-standard tools.

-- Eric

> --
> Colm
> _______________________________________________
> TLS mailing list

-- | @konklone <>