Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

Eric Rescorla <ekr@rtfm.com> Fri, 02 March 2018 01:18 UTC

Return-Path: <ekr@rtfm.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 695FC12426E for <tls@ietfa.amsl.com>; Thu, 1 Mar 2018 17:18:05 -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=rtfm-com.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 gmmr5Qv2_E7j for <tls@ietfa.amsl.com>; Thu, 1 Mar 2018 17:18:03 -0800 (PST)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 A031D120724 for <tls@ietf.org>; Thu, 1 Mar 2018 17:18:03 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id f25so10144039qkm.0 for <tls@ietf.org>; Thu, 01 Mar 2018 17:18:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qh7lSayqJ+yTJ/9ML2ENEj56I4h8m8a/Tt7GgoAfgOo=; b=eG4cO2GLUG10EAk44DDZZ90jMV9XMxZYclWouq/6PZ4UzBf+Y6fHvhe2zHSLzyOigl HIjpfW6szZJp2KcYy40JmI2gCKd5kyM4sfOM/4c/TZp9cQB7lz40E+cL9NO+4LtrnAOX HXX63xEHmA1BD6oQjRu4+Zql7gAB/cPpHsj5KrIuwhXJVAAlsGsSCwbLzm42TPE/DJNt L5n1x7D70uxVqb9Q0unCN3h6Af/QZSFbEa4i9GdOR+MeZAnJ+Lr+aGnnLmkYC1tLSX3E uOEE++rj8D1yCwhh+m8+G2jWky9aut9EqvrRvXwfMl1xgs+TyfQaGTcVmHOFsvU/fpZ8 yhOA==
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=qh7lSayqJ+yTJ/9ML2ENEj56I4h8m8a/Tt7GgoAfgOo=; b=YB3GS3GDWtV33jUsttiaeisFRXCCK1h2bsf2yVMimreufUJ/c2rPPrJ1Gyk3iK6d+3 gzaPwmn5WKSKOd7C+xPxSyikvkoRRTY+j8CuT5OB8lpvxmOgSaBz2CG6hEVkrUpSu4Vi SrIhaiyWjHSbJpty541Bv0ApKP3Jkgd4jGpfaFGNpJjVb3Vzq7YoGAp+bBFD/ipqk5Zf TJpQCoUgcTssesyOcuKVMxare1Crov0aAsRkmTnUPiiQUXPzJWf7SOE4tXf364s/gLPz 1LneNcXsTvUyqJwnfn8LkTdawXui+5O8FVOf6EokpSzGnb/uMsCxxbFAm81lIJXjxmSy 8JkA==
X-Gm-Message-State: AElRT7GjH+3iFF4hVx37HRhkZZLZYu27/TeYTRdCIvKgYGrBZj/Y3KTv rkrCKPGUewEOsbzPz1oGAj2uHz3Sx8itV4kcyLziyBiO
X-Google-Smtp-Source: AG47ELsh05hNu7z+ywa6BhSlAHtuelIUcbKTtX2/9uxwfwCE9r2FndBeulyz6bAbF3rfj3vLySZqXuucJQ+kd8mTI1U=
X-Received: by 10.55.195.145 with SMTP id r17mr5917013qkl.83.1519953482674; Thu, 01 Mar 2018 17:18:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Thu, 1 Mar 2018 17:17:22 -0800 (PST)
In-Reply-To: <CABkgnnVEMj7DGN0GxtSwWSfyDhhdXfXoiwA8XE6M5xgLAHo-iQ@mail.gmail.com>
References: <16A9FD3A-7805-4130-8438-39D0D3E7E3AB@rhul.ac.uk> <87zi3rs7mh.fsf@fifthhorseman.net> <CABkgnnVEMj7DGN0GxtSwWSfyDhhdXfXoiwA8XE6M5xgLAHo-iQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 1 Mar 2018 17:17:22 -0800
Message-ID: <CABcZeBMnxoT1Gq71TNHv0Kq0T9eG=gZP0eAmXobwyD5PdQx_0Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1147a324691864056663bf3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TkBeKrinRDGXruMqxyHEqpAL_hM>
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: Fri, 02 Mar 2018 01:18:05 -0000

On Thu, Mar 1, 2018 at 5:12 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor
> <dkg@fifthhorseman.net> wrote:
> > You could of course check from the front of the plaintext, keeping every
> > non-zero value:
> >
> >   char ptype = 0;
> >   for (i = 0; i < plaintext_len; i++)
> >     if plaintext[i]
> >       ptype = plaintext[i];
>
> What about ?
>
> size_t l[2];
> size_t t[2];
> for (i = 0; i < plaintext_len; ++i) {
>   l[plaintext[i] != 0] = i;
>   t[plaintext[i] != 0] = plaintext[i];
> }
> unpadded_len = l[0] - 1;
> content_type = t[1];


This is fun, but I want to note that many (most) APIs are not zero-copy but
rather involve
SSL_Read() copying data from some internal buffer into a caller supplied
buffer. So
that operation also needs to be made constant time (e.g., by copying the
whole
padded region?), and so on...

-Ekr

_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>