Re: [TLS] Data volume limits

Samuel Neves <sneves@dei.uc.pt> Fri, 01 January 2016 11:19 UTC

Return-Path: <sneves@dei.uc.pt>
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 700291A065C for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 03:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level:
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_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 FFmlbE9Ih24M for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 03:19:31 -0800 (PST)
Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6C01A0545 for <tls@ietf.org>; Fri, 1 Jan 2016 03:19:30 -0800 (PST)
Received: from [192.168.90.50] (bl28-68-171.dsl.telepac.pt [37.189.68.171] (may be forged)) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01BImxI030338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Fri, 1 Jan 2016 11:18:53 GMT
To: tls@ietf.org
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8>
From: Samuel Neves <sneves@dei.uc.pt>
X-Enigmail-Draft-Status: N1110
Message-ID: <56866098.2010803@dei.uc.pt>
Date: Fri, 1 Jan 2016 11:18:48 +0000
User-Agent:
MIME-Version: 1.0
In-Reply-To: <20160101073508.4dd10442c5@ebeb88ce88adeb8>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp.dei.uc.pt [193.137.203.253]); Fri, 01 Jan 2016 11:18:53 +0000 (WET)
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information
X-FCTUC-DEI-SIC-MailScanner-ID: u01BImxI030338
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-10.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25)
X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sxA-v231W6Kb1vd6ES_XAUH0VSc>
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 11:19:34 -0000

On 01/01/2016 06:35 AM, Aaron Zauner 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

OCB is, if anything, worse than GCM when it comes to data volume limits. It has the same confidentiality bounds as GCM
(slightly worse, in fact), but once you hit a collision you also lose authenticity and enable simple forgeries [1].

The real issue here is the block size of AES, not the security bounds of particular modes. Those are by and large all
limited by the birthday bound. You could go with more exotic beyond-birthday modes, but there don't seem to be any being
proposed for TLS. The simple solution to the birthday blues is, of course, to use a larger block.

[1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/General_Comments/papers/Ferguson.pdf