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> Sat, 16 December 2017 10:21 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 EE5A01242F7 for <tls@ietfa.amsl.com>; Sat, 16 Dec 2017 02:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 optD6H5mkJHd for <tls@ietfa.amsl.com>; Sat, 16 Dec 2017 02:21:35 -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 E7A4D1205F1 for <tls@ietf.org>; Sat, 16 Dec 2017 02:21:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9231F41895; Sat, 16 Dec 2017 12:21:32 +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 z_2tqzH48EU7; Sat, 16 Dec 2017 12:21:32 +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 2555EC4; Sat, 16 Dec 2017 12:21:29 +0200 (EET)
Date: Sat, 16 Dec 2017 12:21:28 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Rex <mrex@sap.com>
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171216102128.GA22257@LK-Perkele-VII>
References: <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> <DM5PR14MB1289D532FD2C60EFA1B02F7A830B0@DM5PR14MB1289.namprd14.prod.outlook.com> <20171215195529.GA20237@LK-Perkele-VII> <20171215233006.CF046404B@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20171215233006.CF046404B@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DiZBRO9oekciAiHF4PDx86lD48Q>
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: Sat, 16 Dec 2017 10:21:38 -0000

On Sat, Dec 16, 2017 at 12:30:06AM +0100, Martin Rex wrote:
> Ilari Liusvaara <ilariliusvaara@welho.com>; wrote:
> > On Fri, Dec 15, 2017 at 07:33:44PM +0000, Tim Hollebeek wrote:
> >> 
> >> However, servers are easier to upgrade than clients, which is why you see
> >> some of the server side support you mention.  I know CloudFlare in
> >> particular helped a lot of people cope with communicating with clients who
> >> had different certificate capabilities.  It isn't a bad thing that both
> >> approaches exist.
> > 
> > Also, it should be noted that the past two migrations needed to be
> > compatible with TLS 1.0 and 1.1, which have much less advanced
> > signature negotiation than TLS 1.2 (and 1.3).
> 
> There is an awfully large installed base of borked TLSv1.2 servers.
> 
> If those servers are equipped with a sha256WithRsaEncryption server cert,
> the handshake results are:
> 
>   - TLSv1.0 for SSLv3 ClientHello w/ client_version = (3,1) 
>   - TLSv1.1 for SSLv3 ClientHello w/ client_version = (3,2) 
>   - TLSv1.1 for SSL VERSION 2 CLIENT-HELLO offering (3,3)
>   - chokes and drops network connection
>            for SSLv3 ClientHello w/ client_version = (3,3)
> 
> i.e. there exists a serious interop problem for TLSv1.2 with such servers,
> but there is no problem interoperating with TLSv1.0 or TLSv1.1

What I meant is that in TLS 1.2, one could signal the client
transition status, whereas that is not possible in TLS 1.0 and 1.1.


E.g. suppose we need to transition from SHA-2 to SHA-3.

Pre-transition: signature_algorithms=...,ecdsa_secp256r1_sha256,...
In-transition: signature_algorithms=...,ecdsa_secp256r1_sha3256,ecdsa_secp256r1_sha256,...
Post-transition: signature_algorithms=...,ecdsa_secp256r1_sha3256,...


And server with apropriate SHA-3 certificate chain can send it to the
client. The similar works across signature algorithms.

But this is not possible with TLS 1.0 and 1.1 without very nasty hacks.


However, as noted, many servers do not correctly deal with having two
certificates at the same time. Or server owners think it is too
difficult to deal with them. Dual-signature certificates would be
valuable for those cases.


-Ilari