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.