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

Carl Mehner <c@cem.me> Thu, 20 July 2017 19:21 UTC

Return-Path: <c@cem.me>
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 02417131B76 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 12:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cem.me
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 2hrqPj41B4rr for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 12:21:14 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 BE999131B9D for <tls@ietf.org>; Thu, 20 Jul 2017 12:21:14 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id w45so30521184uac.5 for <tls@ietf.org>; Thu, 20 Jul 2017 12:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OvBtcSsT9LXQ9zopLK5KTY3zFdqfECNmimAgFDGXMP0=; b=cPG9rAZvQtxr9LVXYccfgRTLK1yR1QgWDdZ6mlIfORn2Dvbk195BGB6iEIuX5/Nfuz Pq7I/51GE0zewJQrp0T23Bq0IK5zuFjubxjkXsbMCS++moRNmeQNWkTl0tKMf3hCQlgh jfUb/6KCtwiWyfk8se5RgkPpRw0dVB/bZU7M0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OvBtcSsT9LXQ9zopLK5KTY3zFdqfECNmimAgFDGXMP0=; b=TcphJWjvXLNzVn891P2GZc626nbsOojQsVmtUe7KAT6eKSnJupjnfFrpvEWe5WHbBC iYmicDXhO+EF2OuQDhvayHMGjNKJ7Ue/asbj9mBLpgLdf4THhguoCk2HcDtek3/JenT3 dhqS73vfSLz9Q8pkQHB8lkWIWa7bMSLO3OXwJgiirYx/7Udoov7toPQm35Lh7uxQCQ/S kctTvDlxHc3YTvyDeRbvYXBCw8tcyRKN4N0dlQwycgLnjvtFc2vOBayUwAOKdafdpkI9 OdNOhsiUfm2GEohhqzHnJlzAmpQdetQkVp9UJuyda9NOSHqsUUL1Z1EbAr4Id4MktVdn 9NOA==
X-Gm-Message-State: AIVw111lfDcWhDOpQjQ9QYAHVSUCT1qf+7X+M8ivZVKoYSmhW02dJcJi TzW+etmv9DRtC0hN8gn4MRb9//UpzPV0sqr6WQ==
X-Received: by 10.159.48.8 with SMTP id h8mr2676585uab.196.1500578473686; Thu, 20 Jul 2017 12:21:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.37.174 with HTTP; Thu, 20 Jul 2017 12:21:12 -0700 (PDT)
X-Originating-IP: [2600:1700:1100:a6a0::41]
In-Reply-To: <8d485710-d55e-28b9-3197-ad2d9880f5eb@a-oben.org>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <CAAF6GDc7e4k5ze3JpS3oOWeixDnyg8CK30iBCEZj-GWzZFv_zg@mail.gmail.com> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDeSv+T1ww5_nr6NPgg9k44j7y04tJWC=KeaJF7Gtt+TVQ@mail.gmail.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <CAAF6GDeGKEBnUZZFXX0y0a2J2+sVg8VaHh-4H9bhN0Zzk-x9uA@mail.gmail.com> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDcq6_ML3yHSQTy-t5irYLS10VVzk_R+7nAUKqQpgcCkrQ@mail.gmail.com> <a22d69c80d8d4cd2981cd6ede394c96f@usma1ex-dag1mb1.msg.corp.akamai.com> <F533492A-ACF1-498F-A03C-B829DDFFDD36@arbor.net> <8d485710-d55e-28b9-3197-ad2d9880f5eb@a-oben.org>
From: Carl Mehner <c@cem.me>
Date: Thu, 20 Jul 2017 14:21:12 -0500
Message-ID: <CAEa9xj66Hzpw1OZRfJT_LqqMRbykrKAFaj7GBRb6a1d1VfUMzA@mail.gmail.com>
To: Simon Friedberger <simon.tls@a-oben.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XejuPjijFQ52Ug6CaEoXYB_T6Wg>
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: Thu, 20 Jul 2017 19:21:16 -0000

On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger
<simon.tls@a-oben.org> wrote:
> I would like to point out that a lot of this discussion seems to hinge
> on the following argument:
>
>
> On 17/07/17 13:04, Roland Dobbins wrote:
>> On 16 Jul 2017, at 11:14, Salz, Rich wrote:
>>
>>> I really want to hear an answer to that question from folks who say
>>> they need TLS 1.3 but without it.
>>
>> Being able to continue to utilize vetted, well-understood,
>> standards-based cryptography on intranets once regulatory bodies such
>> as PCI/DSS mandate TLS 1.3 or above - which will happen, at some point
>> in the not-too-distant future.
>
> So the only reason not to use TLS 1.2 for these use cases is that it is
> assumed that some regulator will in the future prohibit not using it.
>
> (I don't think TLS 1.2 is going away any time soon so it will continue
> to be vetted, well-understood and standards-based.)
>
> I think it is up to those regulators to do their job properly and not
> require TLS 1.3 for situations when it does not fullfil the requirements.
> Or conversely if regulators still require TLS 1.3 although it does not
> support the desired traffic inspection maybe they have made that
> decision with good reason.

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.

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?
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.