Re: [TLS] Data volume limits
"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 16 December 2015 15:44 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 13DD51A038A for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 07:44:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mwnINV1EWCmU for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 07:44:23 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7D1A0387 for <tls@ietf.org>; Wed, 16 Dec 2015 07:44:22 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBGFiLGc023753 for <tls@ietf.org>; Wed, 16 Dec 2015 10:44:21 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AQHRN33Tde9nh48KlkmRxpLGJ4HFm57NTcOpgAB95gCAABHcgP//xuuA
Date: Wed, 16 Dec 2015 15:44:20 +0000
Message-ID: <D296D6CB.213C9%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>
In-Reply-To: <BY2PR09MB126923BEB23720E72077364F3EF0@BY2PR09MB126.namprd09.prod.outlook.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: multipart/alternative; boundary="_000_D296D6CB213C9urillmitedu_"
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-1512160262
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/volIj2GqOB6yCW_O5Rr4fuko3Ek>
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 15:44:26 -0000
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. -- Regards, Uri Blumenthal From: TLS <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>> on behalf of "Dang, Quynh" <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>> Date: Wednesday, December 16, 2015 at 07:21 To: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>, "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto: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<mailto:tls-bounces@ietf.org>> on behalf of Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> Sent: Wednesday, December 16, 2015 6:17 AM To: Simon Josefsson Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] Data volume limits On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson <simon@josefsson.org<mailto:simon@josefsson.org>> wrote: Eric Rescorla <ekr@rtfm.com<mailto: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
- 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