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>, "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. >
- Re: [TLS] Data volume limits Watson Ladd
- [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Benjamin Beurdouche
- Re: [TLS] Data volume limits Scott Fluhrer (sfluhrer)
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Russ Housley
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Hanno Böck
- Re: [TLS] Data volume limits Scott Fluhrer (sfluhrer)
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Henrick Hellström
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Andrey Jivsov
- Re: [TLS] Data volume limits Scott Fluhrer (sfluhrer)
- Re: [TLS] Data volume limits Henrick Hellström
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Stephen Farrell
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Bill Frantz
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Andrey Jivsov
- Re: [TLS] Data volume limits Ryan Carboni
- Re: [TLS] Data volume limits Paterson, Kenny
- Re: [TLS] Data volume limits Simon Josefsson
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Henrick Hellström
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Dang, Quynh
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Nikos Mavrogiannopoulos
- Re: [TLS] Data volume limits Yoav Nir
- Re: [TLS] Data volume limits Dang, Quynh
- Re: [TLS] Data volume limits Hubert Kario
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits Salz, Rich
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Dang, Quynh
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits Samuel Neves
- Re: [TLS] Data volume limits Henrick Wibell Hellström
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits sneves
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits James Cloos
- Re: [TLS] Data volume limits Samuel Neves
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits James Cloos
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits James Cloos
- Re: [TLS] Data volume limits Hubert Kario
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Hubert Kario
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Benjamin Kaduk
- Re: [TLS] Data volume limits Florian Weimer