Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 15 December 2017 18:14 UTC

Return-Path: <ilariliusvaara@welho.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 E5E4B1288B8 for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 10:14:39 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 6cLgF6tBuQ_F for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 10:14:37 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A503B12706D for <tls@ietf.org>; Fri, 15 Dec 2017 10:14:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1877DB53FE; Fri, 15 Dec 2017 20:14:36 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id VfLuRrg9jE7z; Fri, 15 Dec 2017 20:14:35 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id ADA19C4; Fri, 15 Dec 2017 20:14:32 +0200 (EET)
Date: Fri, 15 Dec 2017 20:14:32 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171215181432.GA17685@LK-Perkele-VII>
References: <CAAF6GDeeo2xjv1Xu7SFXVZ_zM=XUVJHT=eqH4_-G3+4UHsfvgg@mail.gmail.com> <CACsn0cmMbbT1iAfmxnXHe00dNiqBMyoNkk7e2CyTKWrcdRTtcQ@mail.gmail.com> <CAAF6GDf+GxToBAN83O3NtLO4zJ-8Qax8KjMCGhXv_EhY+NDsKg@mail.gmail.com> <20171215020116.04f9ae15@pc1> <CAAF6GDe79w9XH1GrGvvR-+=uEKfi6GczacUX3Jhy0dL_zW67-Q@mail.gmail.com> <20171215143057.GA17121@LK-Perkele-VII> <MWHPR21MB01897F29048C1B2AB66EA7488C0B0@MWHPR21MB0189.namprd21.prod.outlook.com> <20171215174628.GA17601@LK-Perkele-VII> <CABcZeBOsL0a0xHvVWEus_EY3mUNioaV9fsz89Gt+HeqdHpoyDw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBOsL0a0xHvVWEus_EY3mUNioaV9fsz89Gt+HeqdHpoyDw@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JUSP3aZAei6H__2dyFSdbE5ORsE>
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
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: Fri, 15 Dec 2017 18:14:40 -0000

On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote:
> I'm not quite following how this helps. It's true that if SHA-256 is
> broken, we're in serious trouble, but that's largely because of the fact
> that that's what people's certificates have, so clients really can't refuse
> to support SHA-256 certificates. So, how does adding new algorithms help?
> (That's why I would argue that the existing SHA-384 support doesn't help).

TLS handshake assumes the hash function is strongly collision-
resistant. So if SHA-256/SHA-384 breaks, the handshake hash function
needs to be replaced.

This is separate from certificate signatures. Transitioning this would
be much more nasty than TLS handshake hash, because there is no
backward-compatible way of changing the hash. This is one major reason
why SHA-1 transition took over 10 years (oh, then there is the "fun"
post-quantum transition possibly coming up).


-Ilari