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

Nick Sullivan <nicholas.sullivan@gmail.com> Sat, 08 July 2017 21:16 UTC

Return-Path: <nicholas.sullivan@gmail.com>
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 90DB5126C3D for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 14:16:13 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RpHZDEkTdi80 for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 14:16:12 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 CCE91124217 for <tls@ietf.org>; Sat, 8 Jul 2017 14:16:11 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id p188so50744369oia.0 for <tls@ietf.org>; Sat, 08 Jul 2017 14:16:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OJDFUxMKj0rDFg5pPPFGxxUl6AA/d+sRffCx6xAsopY=; b=Jnxbu6erICeAi9HtGnamr0Up/a6NAYu+vteRMDrMPvavPsLlPnqoyY6cvmZhSdAV0M h0T7mYR19vSaOyb0liqoASsbQIKP4PTVOPRE5TnTXVQGlZDDUclTlwrm4NsR6tNdT37S x5CRAGHydBdI3p2qG5pIoK6LQjrrhm5yeFwCtZqcuNyMVBrIT/13VOZ9djX9q1HfQO3M W6IO+JQ7oykaWwQeXjAWh7oOqcuzoey2CGdOC5hoDMODJn7pbMpQW+nuYmwjcxOOHbY6 BnVivOLi/Vcv+6xoynP9NlufsgEDZizhzpuLKkaDkpm0zNOsCK919rly6yIJaDmK4REP 2vPw==
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=OJDFUxMKj0rDFg5pPPFGxxUl6AA/d+sRffCx6xAsopY=; b=qn2CuE/boRTfWzc3RIgqsHH4FCyndpRwUqRXnxkgDFsp6E4BzkYT1ThdjnSmyOXJLX etnwH/tNsl4YJ6xdmNjxzA//t8oU6CsvC0Wavq9P4JZzD5np9eoR4ZZLgzqnv15/ajaD QEtSiiRTT4APwN9RSRIxVjCXcOuIDJBBxUmBFJGDWDNpgCeAuNP9sSQnv+1cvhWYmeDH iAVBaCY9nLPUg9MtOnxZmehEKz6BnaygfcUGqSI7A5UtxlHndqxHa1f3+T2fMNXJzQMB LFDiM5uuTknXMpBVTNE3seZr0CMymJKnxN1t7fHsuENvHbCY27iT15frKs3+WXi4Xty2 TFgw==
X-Gm-Message-State: AIVw110/gG/5c24/qECsUN9gA4zZqD2Ab7GuWYuzXcXgTJ0Lw88qPIHC jP1AHZDJsikvhPmUwR5MdQSwWOmXzA==
X-Received: by 10.202.213.2 with SMTP id m2mr4828442oig.17.1499548571161; Sat, 08 Jul 2017 14:16:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com>
In-Reply-To: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Sat, 08 Jul 2017 21:16:00 +0000
Message-ID: <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com>
To: Matthew Green <matthewdgreen@gmail.com>, tls@ietf.org
Content-Type: multipart/alternative; boundary="001a113de526e85a140553d4dbc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg>
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 21:16:13 -0000

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
>