Re: [TLS] Data volume limits

Watson Ladd <watsonbladd@gmail.com> Wed, 16 December 2015 03:36 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 61DAC1A21B2 for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 19:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-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 7O1MAuM9lJIL for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 19:36:02 -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 4533B1A21A9 for <tls@ietf.org>; Tue, 15 Dec 2015 19:36:02 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id k189so46157811qkc.0 for <tls@ietf.org>; Tue, 15 Dec 2015 19:36:02 -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:content-transfer-encoding; bh=gWtqSgwCnSKYtlDs0r/GfZ4IaWCZXf9D7SHxQPs6ivw=; b=ceo8MvQkQROVlAllwcxcri67dSH0ROZT0aNAketND7ESFDdLnsH5F3fpQuaOQ1J7LT 45hCO06TKUGHX37e7mfhZ8ZiNoUSBLei3IsPuWmzoAmCruxxYFRYYPbtZ85ebalTw3ym Axi8QH0EzZoSv7dzgHUg/qJ5954/95grUdzOvNIiXApNZDVcUoXsWufhkgbAJmNKLivb aFBKi1u3/ksp40/RBR++UAja5S0p89DHbDOyrQ1Cdo1ixTysMNKVeRHNi/h2vegLJDbO 6AFFJYiuZTl/Fr0aCWnX6T3yziIuRPbWCO+v5311T2t2MHjHd/7sdFGwsTK2ZXtczFoq dHaQ==
MIME-Version: 1.0
X-Received: by 10.13.229.71 with SMTP id o68mr26771894ywe.326.1450236961468; Tue, 15 Dec 2015 19:36:01 -0800 (PST)
Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 19:36:01 -0800 (PST)
In-Reply-To: <5670B774.5050605@streamsec.se>
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> <CABcZeBNSHGGwM41c9QS0G-pnsEkuyA-q6FMhMgv2NQBDmwWwqA@mail.gmail.com> <5670AB96.9000602@streamsec.se> <CACsn0c=FyAn+EqmLTpQj=4U4RckCZFokhc8FLQhvJ1YDVs+aVQ@mail.gmail.com> <5670B774.5050605@streamsec.se>
Date: Tue, 15 Dec 2015 22:36:01 -0500
Message-ID: <CACsn0c=zZwnfR=4ctf91WFcLbD29H9Hrw0FCGfnX-UeQQrO5dg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: =?UTF-8?Q?Henrick_Hellstr=C3=B6m?= <henrick@streamsec.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8WeeBXsxUnD306bRssOfxrbRvxA>
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: Wed, 16 Dec 2015 03:36:03 -0000

On Tue, Dec 15, 2015 at 7:59 PM, Henrick Hellström <henrick@streamsec.se> wrote:
> On 2015-12-16 01:31, Watson Ladd wrote:
>>
>> You don't understand the issue. The issue is PRP not colliding, whereas
>> PRF can.
>
>
> Oh, but I concur. This means that if you observe two same valued cipher text
> blocks, you know that the corresponding key stream blocks can't be
> identical, and deduce that the corresponding plain text blocks have to be
> different. Such observations consequently leak information about the plain
> text, in the rare and unlikely event they actually occur.
>
> However, calling it an exploitable weakness is a bit of a stretch. AES-CBC
> is likely to loose confidentiality slightly faster, for typical plain texts.

The problem is that once you stack enough of those negligible
probabilities together, you end up with something big. Push up to
2^{63} bytes, and the collision probability is 1/4 or 1/2 (I didn't
recompute it just now). And while the definition seems to involve only
a minor loss of security, that's the definition people use for
security.

Using 2^{-64} as a success probability ensures that attackers who can
exploit multiple connections are still defended against. Could we do
better with 2^{-32}? Sure. But at this point we're saying you can
transport over 16 Gbyte of data before rekeying: I think that's enough
for almost all purposes.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.