Re: [TLS] Data volume limits

Watson Ladd <watsonbladd@gmail.com> Tue, 15 December 2015 23:47 UTC

Return-Path: <watsonbladd@gmail.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 F2BD71B2CF8 for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 15:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 Q_4lfpCH_ea5 for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 15:47:58 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 6DD781B2CF4 for <tls@ietf.org>; Tue, 15 Dec 2015 15:47:58 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id u65so20637482qkh.2 for <tls@ietf.org>; Tue, 15 Dec 2015 15:47:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y0ftMvfXvKqFkWSNWblKxBRlSke8jssttLg8pKzP+zk=; b=pzYUpK/Qly3oU691nXYdKohjI1uzRK8xQgjLDkGU7HEwtBXpUeX/wto81CACFAx7e2 FpfRugcNFGA3OHoq4MdMAH5Zvi2viV/eDyuvrDrhmCCsbAejyNh+5tgFhxr5J1Rke1eH Au/bnZg7qoFpT64p85v3WBNYsoEcw1A4wduUoHDOaAHdDVmW76cUxuOkqg71K1PWHhZW +CkmYjik+owXOBzdQhAoOjTJHGOqhb41RDzRsGj3msydiBTu7LZ9d6TBR6e7OF2W0WL1 Ez7eQ+GjDY9QcGENTT4XXu42NIzYx84ZWGpCEyaFqtCFICeyLyaSVfO0frMMiMpi4hvw d9Qw==
MIME-Version: 1.0
X-Received: by 10.13.229.71 with SMTP id o68mr26295219ywe.326.1450223277662; Tue, 15 Dec 2015 15:47:57 -0800 (PST)
Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 15:47:57 -0800 (PST)
Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 15:47:57 -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>
Date: Tue, 15 Dec 2015 18:47:57 -0500
Message-ID: <CACsn0cn4FdS9CRWu0iLo9CfZoyun3EAMJr8DTLV+H1E27VBD+w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Content-Type: multipart/alternative; boundary=94eb2c07ef4a4f67e90526f86b98
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rG0knsfMBMEl2I6bXj4qF9l5VjY>
Cc: 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:00 -0000

On Dec 15, 2015 6: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); 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.  However, that's as true for (say) CBC mode as it is
for GCM

That's correct. And when we crunch the numbers assuming 2^60 is negligible
out comes 2^36 bytes. This doesn't hold for ChaCha20.
>