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

Colm MacCárthaigh <> Wed, 03 January 2018 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 562B71241F5 for <>; Wed, 3 Jan 2018 09:23:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zBGqvFoxLoLK for <>; Wed, 3 Jan 2018 09:23:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 396001270B4 for <>; Wed, 3 Jan 2018 09:23:05 -0800 (PST)
Received: by with SMTP id w1so849850ybe.10 for <>; Wed, 03 Jan 2018 09:23:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AZ30OQTBz0AYa92TnuoyJ9OFjNmaTxo5X7yLpbouPvs=; b=h07/Y2ESxW4w/SIUov0ZkfPrX27ovUHQ7ljMc/PdWqUVV9CsezZCWpQYbNcziFwoRv e86ryn/cWOS4DIEv5pwYgL5Qz4eoSn3nBUv6eEiwHyc/HRYhJ0qhYjLTT188qoacNN3N EFUcTHmp4I6hYVDI2t1pScDt09/I7bvNMFOrJlGoNXVjPN/7aQnBQpWzGQKNi63nAK+B LGFCO3rRzh2d+M9VVSV/MEGlu0k4goCBMmjtW5ahgMfEidLE8H2lc6BC7R2T22pegLNX /7EY3ljuiNpBrXmJejkllGsFlkfBx99T3+Y9qvZpc4jQ7y90j4ezWMUzr3zEd3uxNk0Y UccA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AZ30OQTBz0AYa92TnuoyJ9OFjNmaTxo5X7yLpbouPvs=; b=nkGVzEVYOOyOH7Um3S7dMgehLRC10/JB+OEaZ/Bv34quFI5oxcA1TDtxCe0OkikO+Q LuUxGfQ9MFF/T41dzLIWjHRY6R+gNW2aa7RVS/KoZ1c/KqD4/G2po3K37KzQ0WkVUAhN RJutbNjklyu7pZ4W2FY2UQBj8IEhWcTqzVZ0CCL9gBgMLJyYkyCvJlL0vAjstQ10TtFN F+NPcKGTXkym4KTGQCof7M0ZMVlrKUjEFIa7/Y9A+N2qAhWczDZgcchh6tdkU+yL+lLS 4kXbkQSStWvkI5qLnuHkzdqYjVEDbIyWorD7AGhoMtdgdBGwRF7v8Y37PDUw2eNlm2iJ DDPA==
X-Gm-Message-State: AKGB3mITTNlxCpbfWTNtVXM2OLacVsqk3XjQDB6vtAhPih7pCyQ8Xcwx AlM9t1sO68/5UQmMvEEVbvsI0sJcjvLWO08XN+e8+g==
X-Google-Smtp-Source: ACJfBouXbkECUKBbV2dZLscrh8t5txO+j+S9YBJdM2xN/gax9RY2CSH4bPHQj6aU4NxAvN/UwXvnmvzxXBtxJgxaCE8=
X-Received: by with SMTP id v16mr1969766ybd.425.1515000184147; Wed, 03 Jan 2018 09:23:04 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 3 Jan 2018 09:23:03 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Date: Wed, 3 Jan 2018 09:23:03 -0800
Message-ID: <>
To: Hubert Kario <>
Content-Type: multipart/alternative; boundary="f403045d3304cfa6320561e27755"
Archived-At: <>
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Jan 2018 17:23:07 -0000

On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario <> wrote:
> > *Second: hide all alerts in suspicious error cases*
> > Next, when the handshake does fail, we do two non-standard things. The
> > first is that we don't return an alert message, we just close the
> > connection.
> >
> > *Third: mask timing side-channels with a massive delay*
> > The second non-standard thing we do is that in all error cases, s2n
> behaves
> > as if something suspicious is going on and in case timing is involved, we
> > add a random delay. It's well known that random delays are only partially
> > effective against timing attacks, but we add a very very big one. We
> wait a
> > random amount of time between a minimum of 10 seconds, and a maximum of
> 30
> > seconds.
> Note that both of those things only _possibly_ frustrate attackers while
> they
> definitely frustrate researchers trying to characterise your
> implementation as
> vulnerable or not. In effect making it seem secure while in reality it may
> not
> be.

No, I strongly disagree here. Firstly, frustrating attackers is a good
definition of what the goal of security is. Some times increasing costs for
attackers does come at the cost of making things harder to analyze or
debug, but we shouldn't make the latter easier at the expense of the

In practical terms; it's not that big a deal. For the purposes of research
it's usually easy to remove the delays or masking - I did it myself
recently to test various ROBOT detection scripts; turning off the delay was
a one line code patch and I was up and running, it hardly hindered research
at all.

Similarly, we've already had to reduce the granularity of TLS alerts, so
TLS experts and analysts are used to having to dive into code,
step-throughs, to debug some kinds of problems. I can't how many hours I've
spent walking through why a big opaque blob didn't precisely match another
big opaque blob. We could make all of that easier by logging and alerting
all sorts of intermediate states, but it would be a terrible mistake
because it would leak so much information to attackers.

As for delays possibly making an attackers job harder; I'm working on some
more firm, signal-analysis based, grounding for the approach as the impact
varies depending on the amount of noise present, as well as the original
distribution of measurement due to ordinary scheduling and network jitter,
but the approach certainly makes timing attacks take millions to trillions
more attempts, and can push real-world timing leaks well into unexploitable
in the real world.