Re: [TLS] Data volume limits

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 01 January 2016 07:23 UTC

Return-Path: <ilariliusvaara@welho.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 99C6E1A6F3F for <tls@ietfa.amsl.com>; Thu, 31 Dec 2015 23:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zxapltjyetcR for <tls@ietfa.amsl.com>; Thu, 31 Dec 2015 23:23:34 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 44D281A6F3E for <tls@ietf.org>; Thu, 31 Dec 2015 23:23:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E171C22C3; Fri, 1 Jan 2016 09:23:32 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id R82JSUPBuWiS; Fri, 1 Jan 2016 09:23:32 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 791A1230D; Fri, 1 Jan 2016 09:23:32 +0200 (EET)
Date: Fri, 1 Jan 2016 09:23:31 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Aaron Zauner <azet@azet.org>
Message-ID: <20160101072330.GA25277@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <20160101080140.eb268bd207@ad0158c32e55ba2>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20160101080140.eb268bd207@ad0158c32e55ba2>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/TyreaLNAZnyLm7gcP8Z28HoeM4A>
Cc: "tls@ietf.org" <tls@ietf.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: Fri, 01 Jan 2016 07:23:36 -0000

On Fri, Jan 01, 2016 at 08:04:11AM +0100, Aaron Zauner wrote:
> * Aaron Zauner <azet@azet.org> [01/01/2016 07:35:26] wrote:
> > This might be a good time to point again to my existing AES-OCB
> > draft that hasn't really seen a lot of discussion nor love lately.
> > It expired but I've recently updated the draft (not yet uploaded
> > to IETF as I'm waiting for implementer feedback from two particular
> > sources). The update has something to do with how GCM is implemented
> > in some stacks though, see:
> > https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029
> 
> Having said that, it's probably also a good idea for me to mention
> that the OCB designers point out that:
> ```
> [...]
> 
> Birthday-bound attacks (as well as good cryptographic hygine)
> motivate rekeying well in advance of birthday-bound concerns. In RFC
> 7253 we say that a given a key should be used to encrypt at most 248
> blocks (about 280 terabytes).
> ``` -- http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#ferguson
> 
> Aaron

On topic of existing recomendations, SECSH recommends rekeying after
2^32 blocks (64GB) with 128-bit block ciphers like AES[1].

This is obviously a lot more conservative than the above quoted
recommendation.

Also, it occurs to me that if key update makes sense to even
include depends on the decided threshold. If it is 64GB, then it
makes sense to include. If it is 256TB, then probably not (pseudo-
wrapping TLS sequence numbers is probably not a good usecase,
as data volumes would need to be enormous for that to become an
issue).


[1] It also has recommendation to rekey before 2^32 packets, but
that comes from SSH sequence numbers being 32-bit. TLS sequence
numbers are 64-bit.


-Ilari