IETF Logo Mail Archive

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

mrex@sap.com (Martin Rex) Fri, 15 December 2017 23:15 UTC

Return-Path: <mrex@sap.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 D65C9126DEE for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 15:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 W4Mh2aMWSQAy for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 15:15:35 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BA11241FC for <tls@ietf.org>; Fri, 15 Dec 2017 15:15:34 -0800 (PST)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3yz5rP208xz1JS2; Sat, 16 Dec 2017 00:15:33 +0100 (CET)
X-purgate-ID: 152705::1513379733-0000088A-A21D674F/0/0
X-purgate-size: 1109
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yz5rN642GzGpGl; Sat, 16 Dec 2017 00:15:32 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id BA45D404B; Sat, 16 Dec 2017 00:15:32 +0100 (CET)
In-Reply-To: <DM5PR14MB1289D532FD2C60EFA1B02F7A830B0@DM5PR14MB1289.namprd14.prod.outlook.com>
References: <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> <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>
To: Tim Hollebeek <tim.hollebeek@digicert.com>
Date: Sat, 16 Dec 2017 00:15:32 +0100
CC: Andrei Popov <Andrei.Popov@microsoft.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, "tls@ietf.org" <tls@ietf.org>
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20171215231532.BA45D404B@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lsNMJ7i1yaiUH7Se6d7683X9GDg>
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 23:15:37 -0000

Tim Hollebeek <tim.hollebeek@digicert.com> wrote:
> Because it's easier for the client to decide what the client understands
> than it is for the server to decide what the client understands.  Less
> complexity = less failures.  
> 
> Note that this is how XP was handled for code signing.  The Authenticode
> spec actually made it so if you did things in the right order, XP would only
> see the SHA-1 signature, while more recent operating systems would see both
> the SHA-1 and SHA-2 signatures, ignore the SHA-1 signature, and use the
> SHA-2 signature.  This allowed doubly-signed binaries that worked both on XP
> and non-XP systems.  Unfortunately the technical steps to do so weren't
> widely publicized, but I know some companies took advantage of it.

Now that sounds weird.

If I look at the code signatures on my Windows 7 machine,
e.g.
    C:\windows\ccm\CcmExec.exe

it carries one single digital signature & timestamp _from_Microsoft_ 
created 01-November-2017 and both with sha1RSA.

So it seems some vendors haven't really started migrating away from SHA-1.

-Martin

v2.23.0 | Report a Bug | By Email