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 Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario <[e-mail]> wrote:

> > 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.
>
> No, the goal of security is to stop attacks from being successful, not
> make them harder. Making attack harder is security through obscurity.
> Something that definitely doesn't work for open source software.
>

Unless you're shipping one-time-pads around, cryptography is founded on
making successful attacks highly improbable, but not impossible. There are
measures of likelihood of key and plaintext recovery for all of the
established algorithms. The delay approach is no different, and risk can be
expressed in mathematical ways.  The numbers are lower, for sure, delays
can add a security factor of maybe up to 2^40, but that's still very very
effective and unlike encryption or hashes, do not have to withstand
longterm attacks.

This bears repeating: attempting to make OpenSSL rigorously constant time
made it *less* secure. The LuckyMinus20 bug was much worse than the Lucky13
bug the code was trying to fix. It would have been better to leave it
un-patched (at least for TLS, maybe not DTLS). A delay in the error case on
the other hand, would have made either issue un-exploitable in the real
world. Evaluating that trade-off takes a lots of "grey area" analysis
though; one has to have a sense of judgement for how much risk a complex
code change is "worth", being mindful that complex code changes come with
their own risks.

honestly, I consider this approach completely misguided. If you are OK with
> tying up a socket for 30 seconds, simply start a timer once you get the
> original client hello (or the first message of second flight, in TLS 1.2),
> close the socket if the handshake is not successful in 30 seconds. In case
> of errors, send nothing, let it timeout. The only reason why this approach
> to constant time error handling is not used is because most people are not
> ok with tying up resources for so long.
>

This is real code we use in production; thankfully errors are very
uncommon, but connections also cost very little, in part due to work done
for DDOS and trickle attacks, a different kind of security problem.

Delaying to a fixed interval is a great approach, and emulates how clocking
protects hardware implementations, but I haven't yet been able to succeed
in making it reliable. It's easy to start a timer when the connection is
accepted and to trigger the error 30 seconds after that, but it's hard to
rule out that a leaky timing side-channel may influence the subsequent
timing of the interrupt or scheduler systems and hence exactly when the
trigger happens. If it does influence it, then a relatively clear signal
shows up again, just offset by 30 seconds, which is no use.

-- 
Colm