Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

Andrey Jivsov <crypto@brainhub.org> Fri, 03 March 2017 02:33 UTC

Return-Path: <crypto@brainhub.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736F9129460 for <cfrg@ietfa.amsl.com>; Thu, 2 Mar 2017 18:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 B_Muijw8pl6h for <cfrg@ietfa.amsl.com>; Thu, 2 Mar 2017 18:33:01 -0800 (PST)
Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920641294C4 for <cfrg@ietf.org>; Thu, 2 Mar 2017 18:33:01 -0800 (PST)
Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-01v.sys.comcast.net with SMTP id jd1Xc5PZCEkHpjd1gcSdiV; Fri, 03 Mar 2017 02:33:00 +0000
Received: from [IPv6:::1] ([24.5.144.109]) by resomta-po-01v.sys.comcast.net with SMTP id jd1fcqYwG8jz5jd1gc1zIs; Fri, 03 Mar 2017 02:33:00 +0000
To: Hal Murray <hmurray@megapathdsl.net>
References: <20170303015418.CC005406061@ip-64-139-1-69.sjc.megapath.net>
From: Andrey Jivsov <crypto@brainhub.org>
Message-ID: <fc5460d4-0870-46b6-2dcb-19110ffdf326@brainhub.org>
Date: Thu, 2 Mar 2017 18:32:59 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170303015418.CC005406061@ip-64-139-1-69.sjc.megapath.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfH3tVOs1W5JO6eUaHvUYL+A87IgD3LIENcTPlu4GC2Oum77KKCkQphZCelAjc94Jmek9toovK9KI3Rc0C8jv5qClqrLDOipcVgv8a9HfUDC4I3hzDfFN vG5l3cpEPg45bPODvNN077c9eI7DTmW59orWygaA1dXLO+N487YUkx2tZn0DRoQ0rRIZsFeYrY7exkx5r42JJU5clD2tDFvoqSs=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ZhgAXm36JNOWhd0cFWzhmo21k7o>
Cc: cfrg@ietf.org, tls@ietf.org
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 02:33:03 -0000


On 03/02/2017 05:54 PM, Hal Murray wrote:
> 
> crypto@brainhub.org said:
>> I also think that counting in blocks is cleaner. Counting in bytes is a
>> close alternative. 
> 
> Does counting bytes work?  If the real limit is blocks, I think you will have 
> to round up the byte count when you send a partial block.
> 
> If re-keying too often isn't too expensive, you could get a safe answer by 
> counting bytes and assuming that every byte went in a separate block.
> 
> You might want to round down many more orders of magnitude so the re-key code 
> gets exercised often enough.  Or maybe provide a back door to set the limit 
> so that path can be tested with reasonable resources.
> 

I like the idea of setting the rekey limits, so that the code can be
tested. There is no 3DES in TLS 1.3.


You refer to some under-counting.

The worst case is mod 16 = 1 byte sized TLS records, in which case the
"tails" will only be counted as 1 block per 16 TLS records v.s. desired
16. We are undercounting less than one 16-byte block per record.

One can count in record_size_in_bytes + 16 as one solution (overcount).

However, is it true that 1-byte terminal blocks must be counted as full
16-byte blocks? 1-byte blocks don't seem to directly apply to the proofs
with distinguishing game. With 1-byte plaintext / ciphertext we are not
making statements about two values from the 1^128 members space. Rather,
we are discussing two values from the tiny 256 members space. Also, a
truncated AES-GCM encryption behaves as PRF and not PRP.