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

Russ Housley <housley@vigilsec.com> Fri, 07 July 2017 20:04 UTC

Return-Path: <housley@vigilsec.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 58560131780 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 13:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 BA31mRC2Z71g for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 13:04:24 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B4013176E for <tls@ietf.org>; Fri, 7 Jul 2017 13:04:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8476530053F for <tls@ietf.org>; Fri, 7 Jul 2017 16:04:23 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FDMO8mvamdD4 for <tls@ietf.org>; Fri, 7 Jul 2017 16:04:21 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A943D300268; Fri, 7 Jul 2017 16:04:21 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie>
Date: Fri, 7 Jul 2017 16:04:20 -0400
Cc: IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <CAJU8_nXBFkpncFDy4QFnd6hFpC7oOZn-F1-EuBC2vk3Y6QKq3A@mail.gmail.com> <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kEjCRIs6aab2UBnDXngrujPOs0E>
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, 07 Jul 2017 20:04:26 -0000

Stephen:

> On 07/07/17 19:40, Kyle Rose wrote:
>> an informational draft submitted via the ISE
> 
> ...has nothing to to with this WG and ought consume
> no cycles on this list or in meetings.
> 
> Yes, the ISE is the route 2804 envisages for documenting
> wiretapping schemes such as this.
> 
> The authors of this draft however chose to put "standards
> track" in the header and some of those authors are very
> very well aware of all the nuances here so that was not
> a mistake is my conclusion. So I stand by my statement
> that 2804 says no to this.

As Kyle quoted, RFC 2804 says that we should be talking about the design.  It seems to me the only way to make this proposal more secure is to talk about it.  And, the TLS WG has the people with the proper expertise for that discussion.

The enterprise wants forward secrecy on the public Internet. Terminating the TLS session at the load balancer preserves forward secrecy on the public Internet.

We already had a discussion on this list about requiring a fresh ephemeral DH key for every session.  The consensus was not to require it.  I understand that there are already servers that use the same "ephemeral" DH key for more than one session.  I gather that this is done for performance reasons.  

The conventions described in draft-green-tls-static-dh-in-tls13-01 for using non-ephemeral DH keys has no impact on interoperability.  Discussion of that topic could easily go in an Informational RFC.  Many Informational RFCs describe crypto algorithms.  On the other hand, the protocol between the key manager and the server for installing the non-ephemeral DH key has an impact on interoperability, so it could be in a standards-track document.

In your response, you ignored a fairly significant point in my previous post.

	In some industries, there are regulatory requirements that cannot be
	met without access to the plaintext.  Without some authorized access
	mechanism, the enterprise will be forced to use plaintext within the
	datacenter.  That seems like a worse alternative to me.

From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems like a much better way forward than plaintext throughout the datacenter.

Russ