Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism
David Benjamin <davidben@chromium.org> Thu, 01 March 2018 23:00 UTC
Return-Path: <davidben@google.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 8CD911270FC for <tls@ietfa.amsl.com>; Thu, 1 Mar 2018 15:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.241
X-Spam-Level: ***
X-Spam-Status: No, score=3.241 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 JUcp3ZCuwuhM for <tls@ietfa.amsl.com>; Thu, 1 Mar 2018 15:00:34 -0800 (PST)
Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 5AA6812FA86 for <tls@ietf.org>; Thu, 1 Mar 2018 15:00:34 -0800 (PST)
Received: by mail-qk0-x241.google.com with SMTP id s198so9794057qke.5 for <tls@ietf.org>; Thu, 01 Mar 2018 15:00:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KF3kKhWaV3G3ic5PZm17AezogcnAnwbyLPFNI5Cp+Qg=; b=T4oVQ/WJebZ+YmUYHn3sH7rOoqTCaGVetvZ6U3FLDJHEgGJJ61FqbEy0gR9RbkJku8 kNkPalLpzGa4O39uxdp699sebrc2g+rrLv2ZgOtzhi33BRBLfs8DLq5e/rwYx5fM8aQj cXmXyr+XxEoXSsHGMKyB1/T/aHKm4jkfgiUOY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KF3kKhWaV3G3ic5PZm17AezogcnAnwbyLPFNI5Cp+Qg=; b=tqUVVoFqUOZYfvz0bG/kut5hdRbHbC4oBzM6VuCd/qhVrWDQcqa1oL3kn4eE1/M4t4 N3qSpQMvuydWWA+k/FqnxIZWQ+gUTdQ65ADMcv7O7krB2WzV8f28pRiGp9T4URl4LIQi G/ZX0Lv/0uB/tcaumGlOJYwfaCxHnemdJcl+RYBwzBXgV71uUBpzllNqds1iXID7MOo1 1B/5Ky6qZ5ZRlCUPagdscZO0DPJPJ1M0epGEmhvJ7I7I7ZLiJZNn8E2wvifXIddCiog2 gvRPSLXq93GSSDQQnJtPQEWhv30VlzjVZtOuCof+aguBEJHa4HUgbQAv6+4uZCM984fE 5M9A==
X-Gm-Message-State: AElRT7Ftg+RogE+zTth4X5J31fMPXFjniSfD45pR9/bsNpYOdOyRNWDs RNJVEnhz7ozY96UykmvdCz7nmDV0ny0Qi/B1CCmj
X-Google-Smtp-Source: AG47ELsea2kZSnt4K4ldQjA7OTyoTpKh2B8I0s53m+NseUNND5vcW5V3fr+vBKsTX8NCObLlok7kxEto7MtFD3dhCkw=
X-Received: by 10.55.27.159 with SMTP id m31mr5346138qkh.320.1519945232934; Thu, 01 Mar 2018 15:00:32 -0800 (PST)
MIME-Version: 1.0
References: <16A9FD3A-7805-4130-8438-39D0D3E7E3AB@rhul.ac.uk>
In-Reply-To: <16A9FD3A-7805-4130-8438-39D0D3E7E3AB@rhul.ac.uk>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 01 Mar 2018 23:00:21 +0000
Message-ID: <CAF8qwaDxYuxxrF_cU=JZu=sbH7CqGdTzCys=wasf25aY-SX5Rw@mail.gmail.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114411f8b0a395056661d3b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YDaEE1N34c2LSP7rq-Cneiqgdrs>
Subject: Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism
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, 01 Mar 2018 23:00:36 -0000
The data ultimately needs to be returned to the calling application, presumably some HTTP parser, which in turn passes data up to more calling code and so on. Conversely, the data must have been produced by some also application-level process on the sender, some HTTP serializer, before it was handed off to TLS at all. All of that work is going to freely branch on the length. (Indeed even the traditional read/write APIs of most TLS libraries are the wrong shape here.) Patching just the unpad corner is not very useful without a clearer story for the rest. I'd actually suggest that, for cases where the length needs to remain impervious to timing leaks end-to-end, TLS is the wrong layer to pad. Writing a fully general HTTP parser which avoids leaking the padding length across arbitrary record boundaries not under your control sounds implausible. You'd have to account for padding potentially between *every byte* at the lowest-level serialization. Rather, the higher up the stack you insert your padding, the fewer layers you must traverse. If the process is designed to treat some length as secret in the first place, it probably has the "padding" built-in. E.g., EC private keys are serialized and (at least in good implementations) represented in memory as fixed-width, bounded only by the curve order, even though an individual private key might happen to have a leading zero byte or so. David On Thu, Mar 1, 2018 at 4:53 PM Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote: > Hi, > > I've been analysing the record protocol spec for TLS 1.3 a bit, > specifically the new padding mechanism. I think there's a possible timing > attack on a naïve implementation of de-padding. Maybe this is already known > to people who've been paying more attention than me! > > Recall that the padding mechanism permits an arbitrary number of 00 bytes > to be added after the plaintext and content type byte, up to the max record > size. This data is then encrypted using whichever AEAD scheme is specified > in the cipher suite. This padding scheme is quite important for TLS 1.3 > because the current AEAD schemes do leak the length of record plaintexts. > There should be no padding oracle style attack possible because of the > integrity guarantees of the AEAD schemes in use. > > The idea for the timing attack is as follows. > > The natural way to depad (after AEAD decryption) is to remove the 00 bytes > at the end of the plaintext structure one by one, until a non-00 byte is > encountered. This is then the content type byte. Notice that the amount of > time needed to execute this depadding routine would be proportional to the > number of padding bytes. If there's some kind of response record for this > record, then measuring the time taken from reception of the target record > to the appearance of the response record can be used to infer information > about the amount of padding, and thereby, the true length of the plaintext > (since the length of the padded plaintext is known from the ciphertext > length). > > The timing differences here would be small. But they could be amplified by > various techniques. For example, the cumulative timing difference over many > records could allow leakage of the sum of the true plaintext lengths. Think > of a client browser fetching a simple webpage from a browser. The page is > split over many TLS records, each of which is individually padded, with the > next GET request from the client being the "response record". (This is a > pretty simplistic view of how a web browser works, I know!). The total > timing difference might then be sufficient for webpage fingerprinting, for > example. > > I'm not claiming this is a big issue, but maybe something worth thinking > about and addressing in the TLS 1.3 spec. > > There's at least a couple of ways to avoid the problem: > > 1. Do constant-time depadding - by examining every byte in the plaintext > structure even after the first non-00 byte is encountered. > 2. Add an explicit padding length field at the end of the plaintext > structure, and removing padding without checking its contents. (This should > be safe because of the AEAD integrity guarantees.) > > Option 2 is probably a bit invasive at this late stage in the > specification process. Maybe a sentence or two on option 1 could be added > to the spec. > > Thoughts? > > Cheers, > > Kenny > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] cost of padding removal in TLS1.3 [was: Pos… Nikos Mavrogiannopoulos
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Paterson, Kenny
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Eric Rescorla
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Paterson, Kenny
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Colm MacCárthaigh
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… David Benjamin
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Daniel Kahn Gillmor
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Martin Thomson
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Eric Rescorla
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Martin Thomson
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Nikos Mavrogiannopoulos
- Re: [TLS] Possible timing attack on TLS 1.3 paddi… Paterson, Kenny