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

Roland Zink <roland@zinks.de> Sat, 08 July 2017 22:53 UTC

Return-Path: <roland@zinks.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF6D12F28B for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 15:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHEm0k5-gQS7 for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 15:53:25 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [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 ietfa.amsl.com (Postfix) with ESMTPS id 5D96A12EB8E for <tls@ietf.org>; 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; d=zinks.de; 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=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JVmITQqKA==
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p5DCF4224.dip0.t-ipconnect.de [93.207.66.36]) by smtp.strato.de (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 <tls@ietf.org>; Sun, 9 Jul 2017 00:53:22 +0200 (CEST)
To: tls@ietf.org
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <27e3a03a-f8bf-2eae-775c-33d29b77a2f7@zinks.de>
Date: Sun, 09 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: <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------615BE5578BCBAF02FC7FE3D6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lb42XqeiURDRYGT-LF0Ilgt3tlM>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 
requirements.

Roland


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 <matthewdgreen@gmail.com 
> <mailto:matthewdgreen@gmail.com>> 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:
>
>     https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
>
>     Thanks for your attention,
>     Matt, Ralph, Paul, Steve, and Russ
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls