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

Simon Friedberger <> Thu, 20 July 2017 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83A5C1243F3 for <>; Thu, 20 Jul 2017 16:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MtNjSbiJsHR1 for <>; Thu, 20 Jul 2017 16:14:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2808127599 for <>; Thu, 20 Jul 2017 16:14:52 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <>) id 1dYKeg-00037A-Q8 for; Fri, 21 Jul 2017 01:14:51 +0200
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "" <>
From: Simon Friedberger <>
Message-ID: <>
Date: Fri, 21 Jul 2017 01:14:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: Thu, 20 Jul 2017 23:14:54 -0000

On 20/07/17 21:21, Carl Mehner wrote:
> On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger
> <> wrote:
> I think using TLS 1.2 and waiting will only work up to a point. When
> the regulators do require TLS 1.3 (and that may be years and years
> away), enterprises still need somewhere to go in order to use things
> like IDS and IPS, to look into where application issues are happening,
> and all the other reasons that are laid out for needing this draft.
I agree up to the last point. As you say later there are alternatives
and of course vendors of IDS solutions are not going to implement any of
the potentially more complicated solutions if they don't have to. But it
is entirely possible.
> What's unclear is: Are these organizations willing to take their
> current networking and application designs and begin to slowly rework
> it to support a TLS 1.3-only (real-ephemeral-keys-only) style
> architecture by the time it is required?
For business reasons they essentially must they that they wont but
should TLS 1.3 be accepted as-is they will either do it or be replaced
by more competitive businesses.
> I can say from my enterprise perspective, enterprises have been
> working toward that goal since it was announced that RSA key exchange
> was going away several years ago. We're working with software vendors
> to get the logs that we need from endpoints, making sure that IDS/IPS
> vendors that currently break open streams of TLS cipher text using RSA
> keys are able to switch over to doing TLS termination (with good
> configurations), or use load balancers that can terminate TLS and loop
> it up into an IDS/IPS/WAF before sending the plaintext stream off into
> a new encrypted direction.
> It's not an overnight change, but it is a practical one, and one that
> could end up making these complicated applications that "need"
> static-key-style decryption work more effectively and efficiently.