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

Colm MacCárthaigh <colm@allcosts.net> Thu, 04 January 2018 19:01 UTC

Return-Path: <colm@allcosts.net>
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 292D71275C5 for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 11:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com
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 RkJsnWqBYF7A for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 11:01:05 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA8F1241FC for <tls@ietf.org>; Thu, 4 Jan 2018 11:01:05 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id w128so944855ywa.1 for <tls@ietf.org>; Thu, 04 Jan 2018 11:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zZsBWjW9H90Kk4uP9ahJDo35szV4b8NUHSTdxmSnwNI=; b=LtviApQBMXmDMqmK3gpYH4IyMed6ETrMxKMYWuHeBYc9D2K9AYAWoPb614owg9qF+Y k142wuxkVJJ5hI0zGMD3V05nkln/cLfhNmSLnl4bBZNGwdUAO0V5SMRQug/9Z85Rr5la F5UttaGWaiI7bKLq8xLrenedcue/Pd0XzpYwkKB7v4JpL+meInQF7vG/oPJaCA1ucHFA jsZFRkoWIlyJ/VdpFiVDos8ADCG7jG93OMN35FgrJT0AO0UFded3Yq3bhGLka1+u9dzh BIjqlF2hS1gBkq0i6+qxiL0wJ5SVWvi40YlGAchnr+LdEAWrAKfqLWpz9XY5F5hHgcrn XrCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zZsBWjW9H90Kk4uP9ahJDo35szV4b8NUHSTdxmSnwNI=; b=FnD2deHIHa2OihGMlPYTN6ETRbIV0AI/TwyrQB335htyyIjCZ9j/NPCiNbe4HUk02A AvudsbwNjTHVMOClqwoB8wSxhQYWadOMe3qy8cbS+n12U/OC7ypqY8brFV1Hy6iBmjsz LX3dEi/gzWrSsgZUWJocaUuI7Qs3SRAaGD7mfP5mf0N0ZbZd6EOvyUtq3tYDr8V30jCV 3a2elVx5tZynT5kFxPwkZB1OklnMEbD7u1nLD81yroKkwI0GDIA/zUVONJ+8TlKNPx44 /kiI8l1IViVic8mv1YNAZSC2hnTylouM3rahmTiaGytuXinsVia2D8zZymdoRgqCdEli r6ag==
X-Gm-Message-State: AKGB3mLrOoJ4IR7Yo2TBUeEjF/mGuNU2YW78ARfmBz0RJWkjgALCAPbE TDUbMqiUGVOJ7ssP9qthrAMneMSi3k66t737Y8kAmA==
X-Google-Smtp-Source: ACJfBosTnrSpgAVsPocwhMqQnCTSnX7+14PrhY58Dogsi7TgmRHU/ADBEr3vRvWfTOcqsgQa/bTRpOGu94sho1Y2EEQ=
X-Received: by 10.129.154.22 with SMTP id r22mr527838ywg.418.1515092464069; Thu, 04 Jan 2018 11:01:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.50.70 with HTTP; Thu, 4 Jan 2018 11:01:03 -0800 (PST)
In-Reply-To: <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com>
References: <CAAF6GDeeo2xjv1Xu7SFXVZ_zM=XUVJHT=eqH4_-G3+4UHsfvgg@mail.gmail.com> <3291250.UCJXXru3mW@pintsize.usersys.redhat.com> <CAAF6GDcQY0n6e+dfB-JX4=EpM461k-DtuXt0BU9zpkJWeH+XZw@mail.gmail.com> <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Date: Thu, 4 Jan 2018 11:01:03 -0800
Message-ID: <CAAF6GDewtxWyD__R08222YfYfS5E0tT+m9Zv33R-+rm_49mJ7Q@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0bb4e81f86370561f7f4d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JWvUhiRFMMnX_Ox4bAl9ooSo5f4>
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: Thu, 04 Jan 2018 19:01:12 -0000

On Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario <hkario@redhat.com>; 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