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

Joseph Lorenzo Hall <joe@cdt.org> Fri, 14 July 2017 15:35 UTC

Return-Path: <jhall@cdt.org>
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 697B9131B34 for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 08:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
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 Yu2bbn-jcbIY for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 08:35:38 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D301131A92 for <tls@ietf.org>; Fri, 14 Jul 2017 08:35:38 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id g13so35300959uaj.0 for <tls@ietf.org>; Fri, 14 Jul 2017 08:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; 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; d=1e100.net; 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 10.176.17.26 with SMTP id e26mr5052149uab.94.1500046537128; Fri, 14 Jul 2017 08:35:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com>
In-Reply-To: <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com>
From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Fri, 14 Jul 2017 15:35:26 +0000
Message-ID: <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com>
To: Matthew Green <matthewdgreen@gmail.com>, Nick Sullivan <nicholas.sullivan@gmail.com>, tls@ietf.org
Content-Type: multipart/alternative; boundary="f403045e3e36fe3d1e055448cce1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SOSB2id1MZD5hg3FeORU0IvwulU>
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: 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 <nicholas.sullivan@gmail.com>
wrote:

> 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>
> 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
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871