Re: [TLS] Data volume limits

Hubert Kario <hkario@redhat.com> Mon, 21 December 2015 12:41 UTC

Return-Path: <hkario@redhat.com>
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 991EC1A1A2C for <tls@ietfa.amsl.com>; Mon, 21 Dec 2015 04:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zWB3cA2L9IaA for <tls@ietfa.amsl.com>; Mon, 21 Dec 2015 04:41:44 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BF41A1A28 for <tls@ietf.org>; Mon, 21 Dec 2015 04:41:44 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id DA32242E5C7; Mon, 21 Dec 2015 12:41:43 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBLCfgTh020203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2015 07:41:43 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 21 Dec 2015 13:41:35 +0100
Message-ID: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <r422Ps-10112i-A7598D6B042F444AA21AABEA3552ADF5@Williams-MacBook-Pro.local>
References: <r422Ps-10112i-A7598D6B042F444AA21AABEA3552ADF5@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3516543.47rJPITsM8"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/LQlWS5xjz1wgXTXdFN3Ba0IIFb8>
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: Mon, 21 Dec 2015 12:41:45 -0000

On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote:
> So we have to trade off the risks of too much data vs. the risks
> of a complex rekey protocol vs. the risks having the big data
> applications build new connections every 2**36 or so bytes.
> 
> If we don't have rekeying, then the big data applications are
> the only ones at risk. If we do, it may be a wedge which can
> compromise all users.

if the rekey doesn't allow the application to change authentication 
tokens (as it now stands), then rekey is much more secure than 
renegotiation was in TLS <= 1.2

so if we include rekeying in TLS, I'd suggest to set its limit to 
something fairly low for dig data transfers, that is gigabytes, not 
terabytes, otherwise we'll be introducing code that is simply not tested 
for interoperability

(with AES-NI you can easily transfer gigabytes in just few minutes)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic