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

Dave Garrett <> Sat, 08 July 2017 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53AF212EB01 for <>; Sat, 8 Jul 2017 15:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yPP3GqbjHvu3 for <>; Sat, 8 Jul 2017 15:16:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F772129AAA for <>; Sat, 8 Jul 2017 15:16:53 -0700 (PDT)
Received: by with SMTP id b40so50029970qtb.2 for <>; Sat, 08 Jul 2017 15:16:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=8LuM3W35y8olrmG9HvA/xmftJP6qaPy+Q6Oc4vdcKaI=; b=NN5D4V8lHPCuXJMfw7UMUXyBYK4PkBV5N+RSg5k96XyxoQa6ZTbwI2QrBESCv0d2O+ znaJ71h56M+om5lk3kwU8Lp3eNnh07j2zaqAqGXBNAFzvF230pPHcTKjTBM3iH4SwbFP Z7mNmrcpfBPIVP1zDH8iSxvk/z7QpAzb2l5SReTJyOqITrI0hBXL1rqlXT52N1NQfYUl xjwZfJV+/HF0NT0djfqpVYR0mTi9U3/zZHG7mDPso4ZiXjK+q2qghh0lqHgnuUyNpptr /r5p9qaYSiPWEOi+1mdUGh9afVJowsli1YauCgLaoDFzHIRRic8IYxhxp3PCPKPy2jnb f+AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=8LuM3W35y8olrmG9HvA/xmftJP6qaPy+Q6Oc4vdcKaI=; b=QZZgtV3s11xmw6MKYi4K43b8x616KDDcqrUveSQlD6A/kHrmM6ZySqP02UkxJM+mQH KX2y/GHOCA0PbZH0rAGaQD4tjJ5wRJQghBNVMSFxb2rMPYAOin/9/v0IRR1HrS9waUCa 9WhvNXrGNwFbcTLfFlavCnZsErkCT9JdZ93N+mdCBAFa8N0x3NFGfljWQZisERBHjzXP MT4lvftpDgdG7DGA4mDya0kfb1WL4fIhTsRaCfaXIPhJo/xDov7ecFihPXXLgTC5kPaR UCia9X8WGtwSKo0cvwHwYHsIyag7/pFvLlN4NgdKJSBcofAXnbCgSPZtQMFZrhWOxj71 rESg==
X-Gm-Message-State: AIVw113mzUPXjnNXV1mOAfor7lOhe6BQFFrCnMWFRYuYQK3tDCHhbEUP TiKGBbrpbMWBkqdrg8k=
X-Received: by with SMTP id r10mr32502091qtf.162.1499552212526; Sat, 08 Jul 2017 15:16:52 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id v63sm5366425qkv.46.2017. (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 08 Jul 2017 15:16:52 -0700 (PDT)
From: Dave Garrett <>
Date: Sat, 8 Jul 2017 18:16:50 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
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:16:55 -0000

This thread blew up rather quickly. Replying on a topic with quotes from various posts, below:

On Saturday, July 08, 2017 05:09:12 am Stephen Farrell wrote:
> On 08/07/17 03:06, Ackermann, Michael wrote:
> > Converting all session traffic to clear text is not a viable
> > alternative for ANY enterprises or industries that I am aware of.

Could we please drop the plaintext straw man here? The alternative is building a system that doesn't rely on outdated methods, rather than shoe-horning them into TLS 1.3, not ditching encryption.

> > In
> > particular those in financial sectors. Security policies, legislation
> > and in many cases just good practice would not allow for this. We are
> > compelled by these factors to encrypt all data in motion.  But we
> > still need to manage our applications, networks, servers and clients.
> > Hence the need to decrypt traffic as outlined in this draft.
> That assertion of necessity is blatantly false.
> It is entirely feasible to decrypt and re-encrypt in many
> cases and for that to be efficient and to meet regulatory
> needs.
> If some systems are so badly designed that doing that while
> updating to tls1.3 is a showstopper then that's down to bad
> design or other bad practices. Fixing those is the place to
> spend effort instead of spending effort on breaking TLS.
> Other users of TLS ought not suffer on the basis of such
> bad reasoning.


It is not the job of the TLS WG to make handling internal requirements of organizations easier with their existing systems in spite of the obvious risks that can be avoided.

A drop-in replacement for a theoretically legitimate usecase is also a drop-in replacement for very much illegitimate usecases. Making this a standard is not the way to go here. An argument could be made for informational RFC status rather than standards track, but even then, it's dangerous.

On Saturday, July 08, 2017 01:39:43 pm Watson Ladd wrote:
> On Sat, Jul 8, 2017 at 10:17 AM, Stephen Farrell
> <> wrote:
> > Is it bad faith if the server is compelled to enable this
> > wiretap interface? For a wiretapper this is a great scheme,
> > as they only need to force it to be turned on and accept a
> > tiny bit of data and then they can pick up those packets
> > from anywhere without having to deal with problems at the
> > web server end. So no need to even re-imburse the web server
> > for the intercepted access anymore.
> The same applies to static RSA ciphersuites. I understand your desire
> to move on with TLS 1.3, but we did burn what seemed to be a somewhat
> important usecase to some people, and this draft demonstrates that TLS
> 1.3 can be deployed in datacenters without hurting that usecase. As
> much as I think enterprise networks are suffering from bad design
> decisions that solve problems with boxes and not endpoint changes,
> this is a problem people are claiming to face, and there are some
> security implications.

The organizations that took the easy way at the time now are being told to take a harder way that is more secure. (and are consistently posting to this list with amnesia, acting like we told them to use plaintext) They don't like that; we shouldn't care. We should consider standardizing better solutions for this problem, without regard to how much old systems will have to adapt their design. This has come up on this list MANY times, and each time the end result of discussion was to not revert security decisions made to improve TLS. Releasing a standards track (or even informational) RFC on how to do exactly that using all the old methods, with some tweaks, defeats the purpose of making those security decisions.

I'm getting a bit of déjà vu from this thread, and think the same answer should come as from previous threads on the topic: no, please come up with something new. I don't see the proposed document being anywhere close to getting consensus for adoption by the TLS WG. For the stubborn, an (independent) informational RFC would get far less (but nontrivial) opposition.


Please avoid the "but they'll do whatever they want anyway" comebacks. If the response to not accommodating static keys anymore is to stay with TLS 1.2 forever, then at least they'll be open in their desire to avoid change at all costs. We should not treat this like a hostage scenario.