Re: [TLS] Data volume limits

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 16 December 2015 17:09 UTC

Return-Path: <prvs=9792bcc2b6=uri@ll.mit.edu>
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 6ECF51A1B7F for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 09:09:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 1qGtrX7IzUE2 for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 09:09:38 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id E79291A6FF7 for <tls@ietf.org>; Wed, 16 Dec 2015 09:09:36 -0800 (PST)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBGH9ZnJ030387; Wed, 16 Dec 2015 12:09:35 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AQHRN33Tde9nh48KlkmRxpLGJ4HFm57NTcOpgAB95gCAABHcgP//xuuAgABzTID//8JOAA==
Date: Wed, 16 Dec 2015 17:09:34 +0000
Message-ID: <D29703E1.21AAF%uri@ll.mit.edu>
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <87twnibx5p.fsf@latte.josefsson.org> <CABcZeBO=MQTu2t+EGBn4m2LZt_DKtY3RggF-GcM0S=jAwXeSRw@mail.gmail.com> <BY2PR09MB126923BEB23720E72077364F3EF0@BY2PR09MB126.namprd09.prod.outlook.com> <D296D6CB.213C9%uri@ll.mit.edu> <CACsn0cnb2wScP5m9FnroPLSVcsK1gQVVZdFZpT5kX6q+pGOn5g@mail.gmail.com>
In-Reply-To: <CACsn0cnb2wScP5m9FnroPLSVcsK1gQVVZdFZpT5kX6q+pGOn5g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.8.151023
x-originating-ip: [172.25.177.65]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5A0C0F1B5BCD7C4490147929F123815C@ll.mit.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-16_07:2015-12-16,2015-12-16,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512160288
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0XjN2J5iS4MnW-eij8-K0cckPbE>
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 17:09:41 -0000

On 12/16/15, 10:50, "Watson Ladd" <watsonbladd@gmail.com> wrote:

>On Wed, Dec 16, 2015 at 10:44 AM, Blumenthal, Uri - 0553 - MITLL
><uri@ll.mit.edu> wrote:
>> OK, let me try an extremely naïve approach.
>>
>> Say, an adversary observes a ton of TLS traffic between A and B. Using
>> approach that Watson and others outlined, he can now tell that this is
>>not a
>> truly random stream but a bunch of encrypted data. My question is, from
>> practical real-world point of view - so what? (Of course, beyond the
>>ability
>> to publish a real paper that IND-* has been compromised :)
>>
>> If there are practical consequences, like loss of confidentiality – I’m
>> dying to hear the outline of a practical attack.
>
>The problem is that people design systems assuming something like
>indistinguishability. And so when you violate that assumption, all
>bets are off.

I don’t buy this. AFAIK, TLS has not been designed based on that
assumption. And I’m not making any bets. :)

But:

>What is the actual problem with either implementing rekeying, or
>limiting data to something like 128 GByte per connection?

As far as I’m concerned - none (no problem). And if there’s a way to
enforce rekeying sooner than that (limiting data-under-one-key to a MUCH
smaller amount) - I’d be in favor of that too. I just don’t accept the
above justification for it - and want to be shown how loss of IND property
in TLS context leads to a practical attack.


>>From: TLS <tls-bounces@ietf.org> on behalf of "Dang, Quynh"
>> <quynh.dang@nist.gov>
>> Date: Wednesday, December 16, 2015 at 07:21
>> To: Eric Rescorla <ekr@rtfm.com>om>, "tls@ietf.org" <tls@ietf.org>
>>
>> Subject: Re: [TLS] Data volume limits
>>
>> Hi Eric,
>>
>>
>> I explained the issue before and some other people recently explained it
>> again on this thread. AES has 128-bit block. Therefore, when there are
>>2^64
>> or more ciphertext blocks, there are likely collisions among the
>>ciphertext
>> blocks (the collision probability increases rapidly when the number of
>> ciphertext blocks increases above 2^64 ( 2^n/2 in generic term) ).
>>
>>
>> However, the only information the attacker can gain from ANY pair of
>> collided ciphertext blocks is that their corresponding plaintext blocks
>>are
>> probably different ones because the chance for them to be the same is
>> 1/2^128 (1/2^n in generic term) and this is NOT better than a random
>>guess.
>> So, you don't lose anything actually.
>>
>>
>> As a pseudorandom function, AES completely fails under any mode when the
>> number of ciphertext blocks gets above 2^64.  When the counter is
>> effectively only 64 bits (instead of 96 bits as in TLS 1.3), the data
>> complexity should be below 2^32 blocks because the same input block and
>>the
>> same key can be repeated 2^32 times to find a collision in the
>>ciphertext
>> blocks.  If you want a negligible collision probability, the number of
>>data
>> blocks should be way below 2^32 in this situation.
>>
>>
>> However, the confidentiality of the plaintext blocks is not lost at all
>>as
>> long as the counter number does not repeat.
>>
>>
>> Quynh.
>>
>>
>>
>>
>>
>> ________________________________
>> From: TLS <tls-bounces@ietf.org> on behalf of Eric Rescorla
>><ekr@rtfm.com>
>> Sent: Wednesday, December 16, 2015 6:17 AM
>> To: Simon Josefsson
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] Data volume limits
>>
>>
>>
>> On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson <simon@josefsson.org>
>> wrote:
>>>
>>> Eric Rescorla <ekr@rtfm.com> writes:
>>>
>>> > Watson kindly prepared some text that described the limits on what's
>>> > safe
>>> > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
>>> > limit (2^{36} bytes), even though ChaCha doesn't have the same
>>> > restriction.
>>>
>>> Can we see a brief writeup explaining the 2^36 number?
>>
>>
>> I believe Watson provided one a while back at:
>> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html
>>
>>>
>>> I don't like re-keying.  It is usually a sign that your primitives are
>>> too weak and you are attempting to hide that fact.  To me, it is
>>>similar
>>> to discard the first X byte of RC4 output.
>>
>>
>> To be clear: I would prefer not to rekey either, but the consensus at
>>IETF
>> Yokohama
>> was that we were close enough to the limit that we probably had to.
>>Would be
>> happy to learn that we didn't.
>>
>> -Ekr
>>
>>
>>
>>> If AES-GCM cannot provide confidentiality beyond 64GB (which would
>>> surprise me somewhat), I believe we ought to be careful about
>>> recommending it.
>>>
>>> Of course, the devil is in the details: if the risk is that the secret
>>> key is leaked, that's fatal; if the risk is that the attacker can tell
>>> whether two particular plaintext 128 byte blocks are the same or not in
>>> the entire file, that can be a risk we can live with (similar to the
>>> discard X bytes of RC4 fix).
>>>
>>> I believe 64GB is within the range that people download in a web
>>>browser
>>> these days.  More data intensive longer-running protocols often
>>>transfer
>>> significantly more.
>>>
>>> /Simon
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>
>-- 
>"Man is born free, but everywhere he is in chains".
>--Rousseau.
>