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:34 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 23A8F12940C for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 10:34:32 -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 nkdY4Ii359ik for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 10:34:29 -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 BEFB412706D for <tls@ietf.org>; Fri, 15 Dec 2017 10:34:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 019B848844; Fri, 15 Dec 2017 20:34:28 +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 y0EW1QEkllTC; Fri, 15 Dec 2017 20:34:27 +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 985E6289; Fri, 15 Dec 2017 20:34:24 +0200 (EET)
Date: Fri, 15 Dec 2017 20:34:24 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171215183424.GA17780@LK-Perkele-VII>
References: <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> <CACsn0ckYPpp5nD2jj4Zmx=ZJvqWzHW0tmmXo-9JeKL45+pRUqw@mail.gmail.com> <CABcZeBPPozOsTxxJO63RmHwTr56Wucx6OYW=kvvhosRUHR1ctA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBPPozOsTxxJO63RmHwTr56Wucx6OYW=kvvhosRUHR1ctA@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/mI-klK8gg1Krto1UK-YhNeBby7A>
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:34:32 -0000

On Fri, Dec 15, 2017 at 10:15:23AM -0800, Eric Rescorla wrote:
> On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd <watsonbladd@gmail.com>; wrote:
> 
> > We can force a rotate of all certs in 90 days, and I don't think most
> > people will notice.
> >
> 
> Unfortunately, there are plenty of longterm certificates with lifetimes >>
> 90 days.

Yes, currently the lifetime limit for public certificates is 39 months,
and will be reduced to 825 days (~27 months) effective March 2018.


Then there is backdating to consider. It was seen in both MD5 and SHA-1
deprecations. So maximum certificate lifetime sets limit on how fast
features can be flushed out.

And then there would be enormous amounts of endpoints not supporting
anything better. Those would have to be upgraded.

All in all, a real mess.


-Ilari