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

[Colm MacCárthaigh <[e-mail]>]

On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario <[e-mail]> 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
former.

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.

-- 
Colm