Re: [TLS] Data volume limits

"Dang, Quynh" <> Wed, 16 December 2015 12:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 893C81B2B42 for <>; Wed, 16 Dec 2015 04:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MBLySLhxi14I for <>; Wed, 16 Dec 2015 04:21:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B30B51B2B2B for <>; Wed, 16 Dec 2015 04:21:54 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.355.16; Wed, 16 Dec 2015 12:21:52 +0000
Received: from ([]) by ([]) with mapi id 15.01.0355.012; Wed, 16 Dec 2015 12:21:52 +0000
From: "Dang, Quynh" <>
To: Eric Rescorla <>, "" <>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AQHRN326ECu0fHUB6EGja4Q2uc5EIJ7NTTAHgAAqpwCAAAZ5sg==
Date: Wed, 16 Dec 2015 12:21:51 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY2PR09MB128; 5:9VH64DXbensnvR6Bd3M5gMjW78dgHDYc5nJgeVGDWnEEZChUGCb6OeNxnUwiGeN/vsSFlmRiavRFoYnU7fIUY7MRMh+3bL183QTirPT/2f/pgcm9/y6DHu+BaZougIMYEaYvc4URcqOIy7ZMpqrrGg==; 24:i6AcHseT8yX6IQHE0iLqExhqlWJKDaJqG7NszlSAzGyQms2CwFQewx7T+opN8ynvg451uqPyzQutfhSmyf57uGkE+LzTpkeaer7zq7yHmAE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB128;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR09MB128; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB128;
x-forefront-prvs: 0792DBEAD0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(24454002)(199003)(19580405001)(105586002)(19580395003)(77096005)(40100003)(76576001)(2501003)(106356001)(19617315012)(16236675004)(19627405001)(81156007)(99286002)(86362001)(66066001)(87936001)(107886002)(189998001)(5001770100001)(97736004)(1220700001)(5001960100002)(10400500002)(15975445007)(5003600100002)(101416001)(2900100001)(1096002)(76176999)(5002640100001)(11100500001)(2950100001)(102836003)(3846002)(54356999)(5004730100002)(586003)(6116002)(5008740100001)(50986999)(122556002)(33656002)(19625215002)(74316001)(92566002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR09MB128;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR09MB126923BEB23720E72077364F3EF0BY2PR09MB126namprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2015 12:21:51.3933 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB128
Archived-At: <>
Subject: Re: [TLS] Data volume limits
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Dec 2015 12:21:57 -0000

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.


From: TLS <> on behalf of Eric Rescorla <>
Sent: Wednesday, December 16, 2015 6:17 AM
To: Simon Josefsson
Subject: Re: [TLS] Data volume limits

On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson <<>> wrote:
Eric Rescorla <<>> 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:

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.


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.