Re: [TLS] Additional TLS 1.3 results from Chrome
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 19 December 2017 13:07 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 4CC7C127023 for <tls@ietfa.amsl.com>; Tue, 19 Dec 2017 05:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 9TYIl1bIOWxL for <tls@ietfa.amsl.com>; Tue, 19 Dec 2017 05:07:06 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E664126CD6 for <tls@ietf.org>; Tue, 19 Dec 2017 05:07:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BFE9BE5C; Tue, 19 Dec 2017 13:07:04 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B96lMIdjl4x; Tue, 19 Dec 2017 13:07:03 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B52F4BDD8; Tue, 19 Dec 2017 13:07:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513688823; bh=D5G2wOrd4uYZQy4/24/Bd6Y/ZKr8sElpTAOF2/VWoj4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FEN8kPi5ADQ6GjOzLBeXuago9Q6YzMdTyEoWU4VYZ+uRZ+H3LlQbbT78RuhjlKtIq h3IsN6FUJumeJgN+Ey8NGe+BZnRjbjlEcl/gLOUv2UdyL+VbIZgJO57N9GMfjLWAPO gfQH7jb3UG6InHbG1EOV2PQXXJkqiA6/exgiMpnk=
To: "Salz, Rich" <rsalz@akamai.com>, Eric Rescorla <ekr@rtfm.com>, David Benjamin <davidben@chromium.org>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <CAF8qwaA4su2j-Lh9XRcLbT_Tysg9H24ys=TCC=Rd1bvrFNds7A@mail.gmail.com> <CABcZeBN9ABRSY76NWfqy5QouVE9BJR78nwExNGe-bXsnn1GkmA@mail.gmail.com> <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie>
Date: Tue, 19 Dec 2017 13:07:02 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Q3ArNAr6mt9Grb3iiRW5VRtvCcViooug6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ewLcRpGLlSAQbjXX8x6kwtJU-No>
Subject: Re: [TLS] Additional TLS 1.3 results from Chrome
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: Tue, 19 Dec 2017 13:07:08 -0000
Hiya, On 19/12/17 01:59, Salz, Rich wrote: > However, since extension numbers are essentially infinite, this WG may > consider renumbering key_share to avoid the issue. > >> I think this would be fine, but not imperative. > > I think it would almost be hypocritical if we did not do it. > I'm not sure I agree renumbering is the right reaction, though I don't object to that. This could be a case where it's overall better that those specific devices suffer breakage, and hopefully then do get firmware updated to support TLS1.3 or TLS-without-extended-random-or-dual-ec at some point. WRT extended-random, it seems like the IETF process did work, in that we dropped the work. However, it may also be the case that the attacker's process (if one assumes that somewhere in the background (*) there was an attacker who wanted dual-ec attacks to be more efficient) also worked to at least some extent in that they got that to be deployed in some places, presumably at least partly based on the existence of the (then expired?) draft. I wonder if that argues for some kind of "dropped as a very bad idea" tombstone draft (or even RFC) for such cases? I can imagine that the IETF or TLS WG could do that, but I'm not sure if it'd have helped the developers of bsafe or those printers avoid the problem if such a thing had existed. In the case of extended-random, it is now clear that it is a very bad idea, even if that wasn't the case when the WG chose to not proceed with the work, so such a tombstone draft or RFC could be easily done and could possibly be useful. (I'm about half-convinced of that;-) One reason to think about this is that we have some more-current bad-idea drafts (e.g. draft-green) that we know are dead, but folks not involved in the WG might not be aware of that, so it could be good if those were somewhat more officially put to rest than just sitting forever as expired I-Ds. It'd be a fine thing if the authors of such drafts did that themselves of course, but if not, I'd volunteer to help:-) Cheers, S. (*) To be clear, I am not at all saying the authors of the extended-random draft were part of any attack. If I were the bad actor in such a case, I'd ensure the names that were public weren't in on the plan.
- [TLS] Additional TLS 1.3 results from Chrome David Benjamin
- Re: [TLS] Additional TLS 1.3 results from Chrome Eric Rescorla
- Re: [TLS] Additional TLS 1.3 results from Chrome Tanja Lange
- Re: [TLS] Additional TLS 1.3 results from Chrome Salz, Rich
- Re: [TLS] Additional TLS 1.3 results from Chrome Stephen Farrell
- Re: [TLS] Additional TLS 1.3 results from Chrome Salz, Rich
- Re: [TLS] Additional TLS 1.3 results from Chrome Stephen Farrell
- Re: [TLS] Additional TLS 1.3 results from Chrome Tim Hollebeek
- Re: [TLS] Additional TLS 1.3 results from Chrome Adam Langley
- Re: [TLS] Additional TLS 1.3 results from Chrome Eric Rescorla
- Re: [TLS] Additional TLS 1.3 results from Chrome Ilari Liusvaara
- Re: [TLS] Additional TLS 1.3 results from Chrome Eric Rescorla
- Re: [TLS] Additional TLS 1.3 results from Chrome David Wong