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

Joseph Lorenzo Hall <> Fri, 14 July 2017 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 697B9131B34 for <>; Fri, 14 Jul 2017 08:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yu2bbn-jcbIY for <>; Fri, 14 Jul 2017 08:35:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D301131A92 for <>; Fri, 14 Jul 2017 08:35:38 -0700 (PDT)
Received: by with SMTP id g13so35300959uaj.0 for <>; Fri, 14 Jul 2017 08:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ap2ccjm1ouJUuSNPEBHLr7/rwJNhhdr73d3UxnzNi4E=; b=egF8lHkY6eMTfOrIphDd7bncdKnbevytF0CMydddPHZpgnPI5NbwM1MjllamI/D03T fVxECfqoFo2ZNol3kbUNqiygpxM06JkOduGxWJ9lsEqJfFVchTXw/gtqJFWj8WdWYzJw h0qm7JOI+gLDipdcXNqGMVhF9ZiSXNmEF33qg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ap2ccjm1ouJUuSNPEBHLr7/rwJNhhdr73d3UxnzNi4E=; b=CmOMzGiO29c/05I7LJWTT7AWZ2LDXRy6LZggv1EwErlBGgDxypNMAmgUihYiH3XOaO Vl46OY8xgq0mu2SMo8hZ0bI/PaTcwAe22aUkX2BQQbSJHKAA9z96Tcp8o10NYZF5Pk8X AQ4SCczQy3DGz3TX839rYOjWywHUOGn302wwyxZpv9fJK8oujelLlc0LrRlEhXnaGnym 6y/xJZadUBeojo3z7WOqFuES04/yuZEA6kjrhbu0XtoW0umjaPXqBvyQXegekx8KDPSa lSMC0uGwujYbAARTWFF/QusKypMu4nL1pAqtBNag3JqWVq2x7UV6rX5wlhX3OFD2BwjR tCmg==
X-Gm-Message-State: AIVw111exiCcPcHXjrF9BGhF6vpuUeLbyobM5hhyLiJ7Mfxpa8uACdDF OVHvlg2l+SO04z4q67yRHzT6AE2LGAf6
X-Received: by with SMTP id e26mr5052149uab.94.1500046537128; Fri, 14 Jul 2017 08:35:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Joseph Lorenzo Hall <>
Date: Fri, 14 Jul 2017 15:35:26 +0000
Message-ID: <>
To: Matthew Green <>, Nick Sullivan <>,
Content-Type: multipart/alternative; boundary="f403045e3e36fe3d1e055448cce1"
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, 14 Jul 2017 15:35:40 -0000

Just want to +1 the notion that this should be opt-in for both sides and in
an extension!

On Sat, Jul 8, 2017 at 23:16 Nick Sullivan <>

> Putting questions of whether or not this belongs as a working group
> document, I think there are some necessary requirements for
> intra-datacenter passive decryption schemes that are not met by this draft.
> Specifically, any passive decryption scheme should the following two
> properties:
> 1) Both server and client must explicitly opt-in
> 2) A third party should be able to tell whether or not this feature is
> enabled by observing the stream
> These two requirements protect services on the wider Internet from being
> accidentally (or surreptitiously forced to be) subject to unauthorized
> decryption. The static DH proposal satisfies neither of the above
> requirements.
> What you likely want is something similar to TLS 1.2 session tickets with
> centrally managed session ticket keys. The client would advertise support
> for "passive session decryption" in an extension and the server would
> return an unencrypted extension containing the session keys encrypted by a
> server "passive decryption key". The passive decryption key would be
> managed in the same way as the static DH key in this draft: rotated
> frequently and synchronized centrally.
> A TLS 1.2 session ticket-like scheme provides the same semantics as this
> static DH but provides more safeguards against accidental use outside the
> datacenter. Both client and server need to opt in, it's visible from the
> network, and limits the data visible to the inspection service to the
> session (rather than exposing the master secret which can be used to
> compute exporters and other things outside of the scope of session
> inspection). Furthermore, in the session ticket-like scheme, a *public
> key *could be used to encrypt the session keys, removing the need for a
> secure distribution scheme for the endpoints. The passive decryption
> private key could me managed in a secure location and only the public key
> distributed to the endpoints.
> Session ticket-like scheme advantages vs this static DH proposal:
> 1) Mandatory client opt-in
> 2) Passive indication that scheme is being used
> 3) Decryption service only gets session keys, not master secret
> 4) No need for private distribution system for static keys to endpoints
> In summary, even if this was to be considered as a working group document,
> I think this is the wrong solution to problem.
> Nick
> On Fri, Jul 7, 2017 at 8:03 AM Matthew Green <>
> wrote:
>> 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
> _______________________________________________
> TLS mailing list
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology []
1401 K ST NW STE 200, Washington DC 20005-3497
e:, p: 202.407.8825, pgp:
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871