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

Roland Zink <> Sat, 08 July 2017 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DF6D12F28B for <>; Sat, 8 Jul 2017 15:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7] 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 cHEm0k5-gQS7 for <>; Sat, 8 Jul 2017 15:53:25 -0700 (PDT)
Received: from ( [IPv6:2a01:238:20a:202:5300::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D96A12EB8E for <>; Sat, 8 Jul 2017 15:53:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1499554402; l=12022; s=domk;; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=2cD3Ja28nYbgwhlFbK2m0wrC5bhOP03Y1VY/kGqHIO4=; b=NLaZBtamK5ghyoiugZ2cakPmLqNiUV04/iSjmNc8LSfRXrgJS+TRwp02RPF54j8a+Y OYLhJTWie2ogRTk+aMs2AE3KmJWJCS3SOYhU3iWenC9+tvsD3NjnfkCPZVD0KdrftN1k hs0qdYTGSjAVHplMsAvDofaIxpYAwf9BmctdQ=
Received: from [] ( []) by (RZmta 41.1 DYNA|AUTH) with ESMTPSA id R0566ct68MrMfuK (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <>; Sun, 9 Jul 2017 00:53:22 +0200 (CEST)
References: <> <>
From: Roland Zink <>
Message-ID: <>
Date: Sun, 9 Jul 2017 00:53:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------615BE5578BCBAF02FC7FE3D6"
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: Sat, 08 Jul 2017 22:53:29 -0000

Nice requirements. Will those be applied to all protocols around TLS? 
For example HTML/HTTP/QUIC tend to send data to third parties through 
additional connections and the HTTP referer header tells all those 3rd 
parties the URL used. This is a breach of the users privacy. For 
surveillance no wiretapping is necessary. A secret service just needs to 
infiltrate a few big companies and will get a pretty good overview who 
browse what. The user didn't explicitly opt-in into this although you 
may argue the client software (browser) does. A third party can't tell 
if this feature is enabled or not by observing the stream. So should the 
usage of HTTP/HTTP2/QUIC over (D)TLS in the current form be forbidden? 
The referer header not allowed when TLS is used?

As a server (and client) can always silently forward the unencrypted 
data neither 1) nor 2) can be enforced so I guess those are only should 


Am 08.07.2017 um 23:16 schrieb 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