Re: [TLS] Data volume limits

Yoav Nir <ynir.ietf@gmail.com> Thu, 17 December 2015 11:07 UTC

Return-Path: <ynir.ietf@gmail.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 BA9611ACD0C for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 03:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 cpxFsVPSxtrF for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 03:07:31 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BA11AC416 for <tls@ietf.org>; Thu, 17 Dec 2015 03:07:31 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id l126so16050627wml.0 for <tls@ietf.org>; Thu, 17 Dec 2015 03:07:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K3RsoDrWkw1+WhE0llroOSE2BSU2a75qc1WLE0dJv6Y=; b=LOnfoVw6QgJOWWBOrW2+6Asq5Bd551Ryf4dbEiOsgDqyhH3wP76DJNgERRSR/dWxjP tAjp5UjOc3lIZaDW8v95Y0kgUwD5tMfBD/NIEbufVttERI9zVErVHwGg/bdCDmKsjmOu YlGL295m4iLmHGd+WldnSt3cnQNz6nu/nybt7NFWcJ/5u9BXKnNrt3bIs3VDJTZJ47Uy ii8FbpXBlsw9V6VGn76JyLJpBQ/0q+xW0oh+iDu3phO1U0UmVCpeyPPrN96sGuDrfwjl GK7W5eZL5En9VaobKqCJKm08RNetZEmZyk9HUhKFyqjeYh3y2bGwHQ6aTZsdujKFHS/L SBZg==
X-Received: by 10.28.139.206 with SMTP id n197mr3189765wmd.20.1450350449574; Thu, 17 Dec 2015 03:07:29 -0800 (PST)
Received: from [172.24.248.186] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 198sm1837199wmr.18.2015.12.17.03.07.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Dec 2015 03:07:28 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <1450340361.7118.5.camel@redhat.com>
Date: Thu, 17 Dec 2015 13:07:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F807847B-6185-436C-8012-9456F7F20F72@gmail.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>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/81P_eUKhnc6Jj797NgYgPWr_CVw>
Cc: "tls@ietf.org" <tls@ietf.org>, Simon Josefsson <simon@josefsson.org>
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: Thu, 17 Dec 2015 11:07:32 -0000

> 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