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 19:37 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 ADBE1126DCA for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 11:37:40 -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 4DLzRb7Aq6q0 for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 11:37:38 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30159126C19 for <tls@ietf.org>; Fri, 15 Dec 2017 11:37:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C86B453728; Fri, 15 Dec 2017 21:37:35 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id llAcoTdwG3iX; Fri, 15 Dec 2017 21:37: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 71F3827F; Fri, 15 Dec 2017 21:37:32 +0200 (EET)
Date: Fri, 15 Dec 2017 21:37:32 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Tim Hollebeek <tim.hollebeek@digicert.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171215193732.GA18690@LK-Perkele-VII>
References: <20171215143057.GA17121@LK-Perkele-VII> <MWHPR21MB01897F29048C1B2AB66EA7488C0B0@MWHPR21MB0189.namprd21.prod.outlook.com> <20171215174628.GA17601@LK-Perkele-VII> <CABcZeBOsL0a0xHvVWEus_EY3mUNioaV9fsz89Gt+HeqdHpoyDw@mail.gmail.com> <CACsn0ckYPpp5nD2jj4Zmx=ZJvqWzHW0tmmXo-9JeKL45+pRUqw@mail.gmail.com> <CABcZeBPPozOsTxxJO63RmHwTr56Wucx6OYW=kvvhosRUHR1ctA@mail.gmail.com> <20171215183424.GA17780@LK-Perkele-VII> <MWHPR21MB01893A20A8D0812E880926568C0B0@MWHPR21MB0189.namprd21.prod.outlook.com> <20171215184951.GB17780@LK-Perkele-VII> <DM5PR14MB1289FA656DB8D87DCA0B355F830B0@DM5PR14MB1289.namprd14.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <DM5PR14MB1289FA656DB8D87DCA0B355F830B0@DM5PR14MB1289.namprd14.prod.outlook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gHFIAKJyg5NgW-_vZZeXXvxJjfA>
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 19:37:41 -0000

On Fri, Dec 15, 2017 at 07:14:00PM +0000, Tim Hollebeek wrote:
> So, this has been discussed extensively at the CA/Browser forum, for obvious
> reasons.
> 
> In my mind, it is not so important to identify and define and implement an
> alternative hash.

Well, I would think that having ready to go backup would cut fair
amount of time from transitions.

It should be noted that the two transitions we have seen had backup
algorithm already (SHA-1 in case of MD5 and SHA-2 in case of SHA-1).

> What *is* important is that the protocol and associated software is able to
> support a smooth transition period where people are moving from one
> algorithm to another.

Yes, that is what I was referring with "backward-compatible algorithm
transition".
 
> Ideally, you'd want certificates to be able to have two signatures during
> the transition period, in order to support clients who have transitioned and
> those who have not.  Unfortunately RFC 5280 is deficient in that regard.
> Hosting multiple certificates and switching based on the client is feasible,
> but requires some technical wizardry and isn't possible in all situations.

Yes, there are enormous amount of stacks that have problems with
multiple certificate chains. Ranging from OCSP stapling not working
properly (Nginx+openSSL) to dual-cert not working at all (too many to
list).



-Ilari