Re: [TLS] Data volume limits

Samuel Neves <sneves@dei.uc.pt> Fri, 01 January 2016 19:04 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 34A8B1ACE70 for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 11:04:51 -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_00=-1.9, 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 fgDdK0XOYq65 for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 11:04:49 -0800 (PST)
Received: from smtp2.dei.uc.pt (smtp2.dei.uc.pt [193.137.203.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC4B1ACE6F for <tls@ietf.org>; Fri, 1 Jan 2016 11:04:48 -0800 (PST)
Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.136.212.3]) by smtp2.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01J4HpX007436; Fri, 1 Jan 2016 19:04:17 GMT
Received: from mail.dei.uc.pt (localhost [127.0.0.1]) by mail.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01J1xVr022054; Fri, 1 Jan 2016 19:01:59 GMT
Received: (from daemon@localhost) by mail.dei.uc.pt (8.14.4/8.14.4/Submit) id u01J1xSR022053; Fri, 1 Jan 2016 19:01:59 GMT
Received: from bl28-68-171.dsl.telepac.pt (bl28-68-171.dsl.telepac.pt [37.189.68.171]) by mail.dei.uc.pt (Horde Framework) with HTTP; Fri, 01 Jan 2016 19:01:59 +0000
Message-ID: <20160101190159.407028wg3fz8g10n@mail.dei.uc.pt>
Date: Fri, 01 Jan 2016 19:01:59 +0000
From: Samuel Neves <sneves@dei.uc.pt>
To: Aaron Zauner <azet@azet.org>
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <56866098.2010803@dei.uc.pt> <20160101165821.6cc8a962c4@1620a90cf4e0c0b> <20160101171630.15796qivr4d264xa@mail.dei.uc.pt> <20160101191936.62107c1c1c@f374df84e9aa7e5>
In-Reply-To: <20160101191936.62107c1c1c@f374df84e9aa7e5>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.8)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (smtp2.dei.uc.pt [193.137.203.234]); Fri, 01 Jan 2016 19:04:17 +0000 (WET)
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information
X-FCTUC-DEI-SIC-MailScanner-ID: u01J4HpX007436
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), 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/8D2SUNHzMlkTboAX96X1ZPzAC6U>
Cc: 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 19:04:51 -0000

Quoting Aaron Zauner <azet@azet.org>rg>:

>> On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76
>> total blocks), a block collision is almost guaranteed to have happened,
>> enabling the aforementioned forgeries.
>
> Sure. Would you see any way to improve this situation in the draft,
> i.e. give implementation recommendations or similar?
>

I think the FAQ you quoted before (itself quoting RFC 7253) suggesting  
the limitation of blocks processed to 2^48 is reasonable. Depending on  
the consensus here on what an acceptable success probability for an  
attacker is, you may want to bring that down to 2^32, as is being  
suggested for GCM.

P.S.: Apologies. I had interpreted your diversion into OCB as  
suggesting it as an alternative to GCM to address the data volume  
limitation in question. On a second read, that turned out not to be  
the case, and you were only asking for help.