Re: [TLS] Data volume limits

"Dang, Quynh" <quynh.dang@nist.gov> Tue, 29 December 2015 12:00 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 4FF1B1A8729 for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 04:00:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z70zU1T9zX45 for <tls@ietfa.amsl.com>; Tue, 29 Dec 2015 04:00:52 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A771A872B for <tls@ietf.org>; Tue, 29 Dec 2015 04:00:51 -0800 (PST)
Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 29 Dec 2015 12:00:49 +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.0361.006; Tue, 29 Dec 2015 12:00:49 +0000
From: "Dang, Quynh" <quynh.dang@nist.gov>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AQHRN326ECu0fHUB6EGja4Q2uc5EIJ7NTTAHgAAqpwCAAJE6gIAAzzaAgAAu9YCAAc3M+oARFmPU
Date: Tue, 29 Dec 2015 12:00:49 +0000
Message-ID: <BN1PR09MB124970394E4F115911B712CF3FC0@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>, <BN1PR09MB1249492796831B390E50C7EF3E10@BN1PR09MB124.namprd09.prod.outlook.com>
In-Reply-To: <BN1PR09MB1249492796831B390E50C7EF3E10@BN1PR09MB124.namprd09.prod.outlook.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.222.165]
x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:1+HpTiy6xfn2DDl/CP9vo1xtf6xYY069iIiaIpMj8TVb1RNyBpmnvPq/0xpJxRorT0yG0gvaB2iUg75Ea3A8gNAMJdT7VHzMpZKj9Hqeun0Ekik2WH5Iu7mGKHsOI6oit59G8fHh+9ZDu4yGvrNH7Q==; 24:mVITaID88w4sBFIP7UI2kBlllrlUbNfNb/fUbMr4BTiDcarakqdsgwKwiUv3SUEJuK7rUhZAfTcSTpyniaWHdoOyYDVKhVkx/661rMpxBFE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123;
x-microsoft-antispam-prvs: <BN1PR09MB1234D1A7BFF42C9826AC886F3FC0@BN1PR09MB123.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123;
x-forefront-prvs: 0805EC9467
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(31014005)(53754006)(377454003)(377424004)(199003)(24454002)(101416001)(4001150100001)(189998001)(92566002)(106356001)(5004730100002)(5002640100001)(74316001)(102836003)(2501003)(586003)(76176999)(5008740100001)(107886002)(99286002)(2900100001)(5001960100002)(3846002)(6116002)(1730700002)(1096002)(97736004)(110136002)(81156007)(11100500001)(1220700001)(2950100001)(5003600100002)(54356999)(122556002)(86362001)(87936001)(15975445007)(40100003)(19580405001)(50986999)(77096005)(106116001)(33656002)(450100001)(93886004)(19580395003)(105586002)(66066001)(76576001)(2351001)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; 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: 29 Dec 2015 12:00:49.4275 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8VqghthWfAmrIiuN0BIiav8QuxI>
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: Tue, 29 Dec 2015 12:00:54 -0000

Hi all,

Rekeying too often unnecessarily does not increase any cryptographic security. In addition, it could create other cryptographic issues for the system. The first issue is key collision risk when AES-128 is used and the second issue could be multi-target (multi-key) risk theoretically. 

Therefore, I would suggest not to rekey (as currently specified) too often unnecessarily. 

I think providing a data limit guidance sub-section under the Security Consideration section is one good option to be considered. Users just follow the guidance to set their own data limit(s). 

Quynh. 

________________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Dang, Quynh <quynh.dang@nist.gov>
Sent: Friday, December 18, 2015 10:49 AM
To: tls@ietf.org
Subject: Re: [TLS] Data volume limits

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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls