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:45 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 0EECB126DCA for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 11:45:24 -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 OM-qP2iijfKl for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 11:45:22 -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 4970F126C19 for <tls@ietf.org>; Fri, 15 Dec 2017 11:45:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id AEA84B53D8; Fri, 15 Dec 2017 21:45:20 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id U1WKNNKqCbW6; Fri, 15 Dec 2017 21:45:20 +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-smtp3.welho.com (Postfix) with ESMTPSA id 5D07E2308; Fri, 15 Dec 2017 21:45:17 +0200 (EET)
Date: Fri, 15 Dec 2017 21:45:17 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171215194517.GB18690@LK-Perkele-VII>
References: <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> <MWHPR21MB0189419E69BD53F735C55FFC8C0B0@MWHPR21MB0189.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <MWHPR21MB0189419E69BD53F735C55FFC8C0B0@MWHPR21MB0189.namprd21.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/P5qD3-pnRzzhtivDVeXEIzb343Y>
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:45:24 -0000

On Fri, Dec 15, 2017 at 07:25:20PM +0000, Andrei Popov wrote:
> > 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.
> 
> > Hosting multiple certificates and switching based on the client is feasible,
> > but requires some technical wizardry and isn't possible in all situations.
> 
> For my understanding, why is the former (double-signed certs, where either
> signature is trusted) better than the latter (multiple certs with different
> algorithms)? The latter is currently supported by some TLS servers.

Because the latter is only supported by some TLS servers.

And even if the TLS server nominally supports multiple certificates,
there may be other issues. E.g., OCSP stapling does not work correctly
with multiple certificates.



-Ilari