IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Sun, 16 July 2017 09:09 UTC

Return-Path: <mellon@fugue.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 2159313192D for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 02:09:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 z5j96BO4sX_x for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 02:09:06 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 8C0BD13191C for <tls@ietf.org>; Sun, 16 Jul 2017 02:09:04 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id v190so7105179pgv.2 for <tls@ietf.org>; Sun, 16 Jul 2017 02:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U1AIinp0A8xoX74IyI0nF/rFnyPuDZs9xWhJI+1jseU=; b=HmuXOsLymWrv9OemQVUOY99Qi5qadIqronQDQWt/v4HPjetEM1fwz/5qIsny9tLNYN tu04YYz2FGXqLv/8sYyByGmxSEb6nT4d7MVlVcD5xmtZ0hYhbiCPfGFwTiG0ASXEp8AO RymvpP67XR8sJolpURTnYj0UjLBYbxMNOTMqAeXTBNUU4g5UA8bl0Y4/YAcFZ0uTiLTa cxeLgIQEbYCilL1NcuezZXhLqrZk4h6OrY+duAlHMefKLaZG7b2+Q6OdqKkBdRU5D4ZY TjgD46rgFSi5qRLTSkWdL9ZtkMD/FQJXKIAze9yQI7JNphPb14sEOBdrudVpd13p6NqN OGyw==
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=U1AIinp0A8xoX74IyI0nF/rFnyPuDZs9xWhJI+1jseU=; b=ljgl0DI4zCoJ5YiyEx/cj0p9SlZGAOeB8sQNY2AHPybMUoqljdK8RWRMb6Mq6mun29 yxra9PldfYsDEUwKcwmtuhL2Sl0Uw8NIyR0qXkjy35QfXaWid2JO9CwOIhqcFCiN6VR/ g/XmoSmiOyhkX+9I5aaqfQ6mBb4OCotChJKSPbE05PGmUZb8Ox+HUFPBMnyU8HaXEcM5 q4AJ+gTen+NWKPms5PLpVVS58mgV/IGjBzHhUN3X7MTvsNsJfYToa19tPHuEENbA5A9Y p6GATJVxmB/0ornjDkP0D2tcyZMZWyGcUCDIFC3jD3it4jqchzpxIBoA/ItIXfWz8uxM 4taw==
X-Gm-Message-State: AIVw111X+nBwMfTZtd6LvKLwiaaajql24J3Pf3KP+5NMdVUTbIsEj+x8 /QKleDCo1ZH7JCrbrFsAH51rZ3xfq0gY
X-Received: by 10.84.231.16 with SMTP id f16mr24877208plk.131.1500196144146; Sun, 16 Jul 2017 02:09:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 02:08:23 -0700 (PDT)
In-Reply-To: <CAAF6GDcq6_ML3yHSQTy-t5irYLS10VVzk_R+7nAUKqQpgcCkrQ@mail.gmail.com>
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>
From: Ted Lemon <mellon@fugue.com>
Date: Sun, 16 Jul 2017 11:08:23 +0200
Message-ID: <CAPt1N1m_Zi_2faa8KHcXnic4QjXCEDkwnf=RTbo-Crvh6nMC+g@mail.gmail.com>
To: Colm MacCárthaigh <colm@allcosts.net>
Cc: "Salz, Rich" <rsalz@akamai.com>, Matthew Green <matthewdgreen@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403043601824400cb05546ba272"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8pr8OSnakZJudtHhQI-IBpCATFc>
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: Sun, 16 Jul 2017 09:09:08 -0000

What it means for users to be denied the benefits of TLS 1.3 is that they
don't get, for example, perfect forward secrecy.  Since the proposal was to
do away with that anyway, but for all users, not just some users, that
doesn't seem like it is better than just continuing to use TLS 1.2.  It's
already possible to configure both TLS 1.2 clients and servers to not use
obsolete encryption algorithms.  Most of the other improvements in TLS 1.3
probably don't apply to the use cases you are talking about.

So no, it's not self-defeating to say "continue using TLS 1.2 for now in
your use case while we study this issue and try to figure out if there's a
way forward that doesn't break TLS 1.3."

On Sun, Jul 16, 2017 at 11:04 AM, Colm MacCárthaigh <colm@allcosts.net>
wrote:

>
>
> On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich <rsalz@akamai.com> wrote:
>
>> I would also like to understand why TLS 1.2 is not sufficient for, say,
>> the next five years.
>>
>
> It probably is ... but isn't that the problem? If the answer is "Just let
> them stay on TLS1.2", I find it very hard to interpret the arguments
> against all of this as resulting in anything other than grand-standing.
> Clearly the users would be no better off, and also end up denied the other
> benefits of TLS1.3.
>
> This seems self-defeating, when there is so easy a path that may improve
> things for all cases (forbid static-DH, add an opt-in mechanism instead).
>
> --
> Colm
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

v2.23.0 | Report a Bug | By Email