Re: [TLS] Data volume limits

Eric Rescorla <ekr@rtfm.com> Tue, 15 December 2015 23:48 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24151B2CF8 for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 15:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
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 Th0Sa7PTp0Xy for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 15:48:53 -0800 (PST)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 8660C1B2CF4 for <tls@ietf.org>; Tue, 15 Dec 2015 15:48:50 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id t125so39753973qkh.3 for <tls@ietf.org>; Tue, 15 Dec 2015 15:48:50 -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:content-type; bh=fbklgIgdvuQG+fr9TABTa+18JwSxhaFNLvVvCCFuL60=; b=Tf9+viJZ9t2YNJztYC3ou3DAIzTMx7FnbcoUPnuzWPolh3VvcphN2Uxq80BDMdsweT heSLQeWFea0CwM8gJvzeRWSmQdH973EFgWEi8hInmZF3uukc28Flot70cwK9g6pQn2My ZNBUnFhVLlWtJwbApVFldTHrSlO68/WQUS7+jOTCirlXZr9RKGYFa6mY1WnsXlEQ/FOe GJvHjBUzV1k/woFZONjhm1meP7W9HE4t7fdsaLCr1eymgrthwL1iVg06jhV/N2+cZ4Ol AXmTECirDGm5NEBPhXcndWP4qkdn9rDE79/LOT3QILbhl4trAih+EENxwpcUsOvDAp+O UMYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fbklgIgdvuQG+fr9TABTa+18JwSxhaFNLvVvCCFuL60=; b=KBTyYkq0pijqOSYJY8JUZtS5THu3hB9372J2hbjTuRGVkyjlyg8EnVFMS2hxWcMzfG OlGGy+U9UCKt6eqDl7sVM8z1HoOeRnz1s4ULE1KlN9QIca8qtYHuPorQ6b19WU6RjXWI jJYw8c4RpkmI7zMJIFCpvp7isBuJopIW4JGP2Ml237TnNPN2Gg1lc5tceHAw97CSf6ge SN3H3ItdNT+6dmL+OCyIoK3BlRm1sJ+XMpQs5VZ/Kc4zB4OVBzkkHWvNvTCsXtq9k4VZ PhvjHDekXXa6NDAq+DrJD83xw2pn+FulxPclWfa5FMzASZNCQGRiy4/hRF/ml44JLoYc 5n3Q==
X-Gm-Message-State: ALoCoQmI80yLYNf6oQmgZLClgKkVV9GIQlnlACXDsctjQMMBafCuV2XxYzeXgUQQ3UN3xxoF81rd3pMLjazO3otDtBhwxwcOjA==
X-Received: by 10.13.193.4 with SMTP id c4mr10623080ywd.192.1450223329682; Tue, 15 Dec 2015 15:48:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 15:48:10 -0800 (PST)
In-Reply-To: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com>
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <e007baa2f53249d49917e6023e578bc0@XCH-RTP-006.cisco.com> <CACsn0ckSo-affRmsTZaodCJZsFisPygnhk9=OZuV0_9SVMbUxQ@mail.gmail.com> <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 15 Dec 2015 15:48:10 -0800
Message-ID: <CABcZeBNSHGGwM41c9QS0G-pnsEkuyA-q6FMhMgv2NQBDmwWwqA@mail.gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Content-Type: multipart/alternative; boundary="001a114caa9e695bbf0526f86e61"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/auWGxJ-J2K4MLToN66bxNOqGEm8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Data volume limits
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 15 Dec 2015 23:48:55 -0000

On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) <
sfluhrer@cisco.com> wrote:

>
>
> > -----Original Message-----
> > From: Watson Ladd [mailto:watsonbladd@gmail.com]
> > Sent: Tuesday, December 15, 2015 5:38 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: Eric Rescorla; tls@ietf.org
> > Subject: Re: [TLS] Data volume limits
> >
> > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> > <sfluhrer@cisco.com> wrote:
> > > Might I enquire about the cryptographical reason behind such a limit?
> > >
> > >
> > >
> > > Is this the limit on the size of a single record?  GCM does have a
> > > limit approximately there on the size of a single plaintext it can
> > > encrypt.  For TLS, it encrypts a record as a single plaintext, and so
> > > this would apply to extremely huge records.
> >
> > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show a
> > quadratic confidentiality loss after a total volume sent. This is an
> exploitable
> > issue.
>
> Actually, the main result of that paper was that GCM with nonces other
> than 96 bits were less secure than previous thought (or, rather, that the
> previous proofs were wrong, and what they can prove is considerably worse;
> whether their proof is tight is an open question).  They address 96 bit
> nonces as well, however the results they get are effectively unchanged from
> the original GCM paper.  I had thought that TLS used 96 bit nonces
> (constructed from 32 bit salt and a 64 bit counter);


TLS 1.3 uses a 96-bit nonce constructed by masking the counter with a random
value.

were the security guarantees from the original paper too weak?  If not,
> what has changed?
>
> The quadratic behavior in the security proofs are there for just about any
> block cipher mode, and is the reason why you want to stay well below the
> birthday bound.


The birthday bound here is 2^{64}, right?

-Ekr


>   However, that's as true for (say) CBC mode as it is for GCM
>
>