Re: [TLS] Data volume limits

"Dang, Quynh" <quynh.dang@nist.gov> Fri, 18 December 2015 15:50 UTC

Return-Path: <quynh.dang@nist.gov>
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 BB9571B3424 for <tls@ietfa.amsl.com>; Fri, 18 Dec 2015 07:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 NwBD-PX70_4X for <tls@ietfa.amsl.com>; Fri, 18 Dec 2015 07:49:57 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FC81B36A5 for <tls@ietf.org>; Fri, 18 Dec 2015 07:49:56 -0800 (PST)
Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.355.16; Fri, 18 Dec 2015 15:49:37 +0000
Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0355.012; Fri, 18 Dec 2015 15:49:37 +0000
From: "Dang, Quynh" <quynh.dang@nist.gov>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AQHRN326ECu0fHUB6EGja4Q2uc5EIJ7NTTAHgAAqpwCAAJE6gIAAzzaAgAAu9YCAAc3M+g==
Date: Fri, 18 Dec 2015 15:49:36 +0000
Message-ID: <BN1PR09MB1249492796831B390E50C7EF3E10@BN1PR09MB124.namprd09.prod.outlook.com>
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <87twnibx5p.fsf@latte.josefsson.org> <CABcZeBO=MQTu2t+EGBn4m2LZt_DKtY3RggF-GcM0S=jAwXeSRw@mail.gmail.com> <CAFewVt7wL9bY0S6Rm2nJMgYbN-FwkEo66JQMm9Fq5k0LDdP9xA@mail.gmail.com> <1450340361.7118.5.camel@redhat.com>, <F807847B-6185-436C-8012-9456F7F20F72@gmail.com>
In-Reply-To: <F807847B-6185-436C-8012-9456F7F20F72@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-originating-ip: [129.6.105.150]
x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:e27RvFHGlTL2C9Ssz1Wptm4CzKl9PiVahoy8ey9A0kRl6+mzDohk2/HQXlYV53lWrgRm+IGVD248TuyGGkYCKXKSQqlB1TBguKSK6Ksm9oepzD/tPq7bIRBLuhZxQjwveEvF/YcLfR+xLCy5sHszhg==; 24:Qi2BigFIJME+l4vUQhVNZeQaeOkQJgBMbvBlA6GjjEd/IsBkRsPbG7iX07YtSXBh7k5/gs/WsQAGHJ6pHGBIxW8TAAyVaXg6IJuFSL8KKQY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122;
x-microsoft-antispam-prvs: <BN1PR09MB122F8A194D604FEB63EECAAF3E10@BN1PR09MB122.namprd09.prod.outlook.com>
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:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122;
x-forefront-prvs: 07943272E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377424004)(377454003)(199003)(19580395003)(15975445007)(2900100001)(107886002)(3846002)(5003600100002)(66066001)(6116002)(87936001)(586003)(189998001)(1220700001)(5008740100001)(450100001)(1096002)(5001960100002)(110136002)(97736004)(1730700002)(33656002)(2501003)(4001150100001)(81156007)(5002640100001)(102836003)(2950100001)(76176999)(10400500002)(5004730100002)(77096005)(92566002)(50986999)(86362001)(40100003)(54356999)(106356001)(76576001)(122556002)(106116001)(105586002)(2351001)(11100500001)(74316001)(93886004)(19580405001)(99286002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2015 15:49:36.6087 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/myYwKwiLY2-m3S-NO0V5Ba7xSws>
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: Fri, 18 Dec 2015 15:50:00 -0000

The collision probability of ciphertext blocks also depends on the size of the plaintext (record size  in a TLS implementation) in each call of the GCM encryption function.  Let's call each plaintext  to be 2^x 128-bit blocks.

TLS 1.3 uses 96-bit IV. 

If someone wants the collision probability below 1/2^y such as 1/2^24 or 1/2^32 (2^32 = 4,294,967,296 and 2^24 = 16,777,216 ), the total number of plaintext blocks under a given key must be 2^((96 + x - y)/2) or lower.  

So, 2^((96 + x - y)/2) 128-bit blocks are the limit to achieve  IND-* with GCM. 

If someone does not need IND-* property, the above restriction is not needed.

Quynh. 


________________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Yoav Nir <ynir.ietf@gmail.com>
Sent: Thursday, December 17, 2015 6:07 AM
To: Nikos Mavrogiannopoulos
Cc: tls@ietf.org; Simon Josefsson
Subject: Re: [TLS] Data volume limits

> On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>
> On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote:
>
>> Therefore, I think we shouldn't add the rekeying mechanism as it is
>> unnecessary and it adds too much complexity.
>
> Any arbitrary limit for a TLS connection is almost guaranteed to cause
> problems in the future. We cannot predict whether 2^x should be
> sufficient for everyone, and I'm pretty sure this will prove to be a
> terrible mistake. TLS is already being used for VPNs and transferring
> larger amounts of data in long lived connections is a reality even
> today. The rekey today happens using the reauthentication mechanism,
> which has very complex semantics. Converting these to a simpler and
> predictable rekey mechanism would be an improvement.

Agreed. The alternative to having a rekey mechanism is to push the complexity to the application protocol, requiring it to be able to use more than one connection to transfer all the data, which may require some sort of session layer to maintain state between connections.

So unless we can guarantee or require that every algorithm we are going to use is good for some ridiculous amount of data (2^64 bytes may be enough), we need rekeying.

Yoav

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls