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

Richard Barnes <> Fri, 07 July 2017 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40F5D131460 for <>; Fri, 7 Jul 2017 06:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, 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 cI3ISP8dpqE3 for <>; Fri, 7 Jul 2017 06:02:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 219AE1201F8 for <>; Fri, 7 Jul 2017 06:02:07 -0700 (PDT)
Received: by with SMTP id c11so46189109wrc.3 for <>; Fri, 07 Jul 2017 06:02:07 -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=ISvv6U88VsKwb9R5lhHy/GQBZ5bMbyY42Hm2teeCvMQ=; b=Iygy6+35yofYAepq3rpgGfzDxf7TvwwWqLiqOREQVHLfFV+EGjdMbtY6/KR+BH0Gat RXBns1vxywR+h91dZMEZXXkDWn5LDQ+oXv4kYsCHIaOB7bFrsDMoAYs/unyYv7AIsXym /8f3rSFmujqXFAB0uCt2HF6+oLVWmuD4TOimTHApD/+Xwg7aOqLijUXTwnJA/HiswQfa N5zR6FUOkdet7uM0JkOlZLWS8QdHKMuE436gzCAFhdp3xW7fKBATIFVwfNMhn4QVSayR Ve9VZ2RuDBKvkNBsBvEuJczBoBVtr6psm7Bj94PhuehVq8E+3AOfwqnn+xmlrzLG20AC IP0g==
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=ISvv6U88VsKwb9R5lhHy/GQBZ5bMbyY42Hm2teeCvMQ=; b=ksnhzaOjfCXSZAmtW6WmpidcJ1OZH1qFo70aTQ1FBY6nxReOdRvhW5F85HAGDhh2O1 ngWHAHu5noOhud1ttMLel+SPVH2rIA4AwMjcP9/QJ9A0fsA3pimpH+GqGV6YzS2GOH3L K9iz60CshPCIK4yirAvBfSv7kyT7HjvA0WSxV0ddNH5DZ6EpPrjAHpS4N8Zf61VWOJNf OzDP9XPz3NoBZlGKjXbtlf53Sa3gZrljDHSvhx4qXLvJSag41s/rraQ2hapvoQTi3ZtC yvowTpFWBwQkQwKwHX3GSBVMd5LTcx8axi5SlWaTYa2W9Yz4MjN4mNRmGu+ldUJ7WDcl NYCg==
X-Gm-Message-State: AIVw113mBQpyYvHX9Yw/ps5DTkdXyMD6AGf1o9IAQ2iI8HJux/4QpRie 8AtKjvoLseBwlEADpjUwOwov5zrjBPxx
X-Received: by with SMTP id y101mr740303wrb.168.1499432525466; Fri, 07 Jul 2017 06:02:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 7 Jul 2017 06:02:04 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Richard Barnes <>
Date: Fri, 7 Jul 2017 09:02:04 -0400
Message-ID: <>
To: Matthew Green <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="f403045f4d020bb6920553b9d753"
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: Fri, 07 Jul 2017 13:02:11 -0000

Without taking a position on whether this group should take on this work, a
couple of questions about alternative approaches (sorry if these have been
answered before):

1. It seems like the requirement here is that the DH private key be
*predictable* by the monitoring box based on some static configuration.
That is, it seems like you could have keys that are predictable to the
monitoring device, but still vary over time, something like setting the
private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom).
Without having done much analysis, this seems more conservative than making
things entirely static. Is there a reason to prefer the purely static
approach besides simplicity?

2. You could avoid changing how the DH works altogether by simply exporting
the DH private key, encrypted with a key shared with the monitoring device,
in a server extension.  (Not in EncryptedExtensions, obviously.)  This
would also have the benefit of explicitly signaling when such monitoring is
in use.  The only real challenge here is that the client would have to
offer the extension in order for the server to be able to send it, which I
expect things like browsers would be unlikely to do.  However, given that
the target of this draft seems to be intra-data-center TLS, perhaps this is
a workable requirement?


On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green <>

> The need for enterprise datacenters to access TLS 1.3 plaintext for
> security and operational requirements has been under discussion since
> shortly before the Seoul IETF meeting. This draft provides current thinking
> about the way to facilitate plain text access based on the use of static
> (EC)DH keys on the servers. These keys have a lifetime; they get replaced
> on a regular schedule. A key manager in the datacenter generates and
> distributes these keys.  The Asymmetric Key Package [RFC5958] format is
> used to transfer and load the keys wherever they are authorized for use.
> We have asked for a few minutes to talk about this draft in the TLS WG
> session at the upcoming Prague IETF. Please take a look so we can have a
> productive discussion.  Of course, we're eager to start that discussion on
> the mail list in advance of the meeting.
> The draft can be found here:
> Thanks for your attention,
> Matt, Ralph, Paul, Steve, and Russ
> _______________________________________________
> TLS mailing list