Re: [Cfrg] [TLS] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 21 November 2016 20:42 UTC

Return-Path: <ilariliusvaara@welho.com>
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 0EB6F129BA1; Mon, 21 Nov 2016 12:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham 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 oOY9D_2gHFtO; Mon, 21 Nov 2016 12:42:39 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D8A9B129BA2; Mon, 21 Nov 2016 12:42:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A7A2413AA7; Mon, 21 Nov 2016 22:42:37 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id GtxDQNHMU70p; Mon, 21 Nov 2016 22:42:37 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4D96D283; Mon, 21 Nov 2016 22:42:37 +0200 (EET)
Date: Mon, 21 Nov 2016 22:42:31 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
Message-ID: <20161121204231.GA9484@LK-Perkele-V2.elisa-laajakaista.fi>
References: <DM5PR09MB1467742B07519F09EE8FA0B2F3BD0@DM5PR09MB1467.namprd09.prod.outlook.com> <CABkgnnVS5rTnoGHs1fxAy2eBrCKerZbQmLNzzrhKBm4eiHhceQ@mail.gmail.com> <DM5PR09MB14673CCBCDC107D5912F8669F3BC0@DM5PR09MB1467.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <DM5PR09MB14673CCBCDC107D5912F8669F3BC0@DM5PR09MB1467.namprd09.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/y0t5KmhJx-U1Hw2DESBwmL45GWs>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [Cfrg] [TLS] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5
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: Mon, 21 Nov 2016 20:42:41 -0000

On Mon, Nov 14, 2016 at 02:54:23AM +0000, Dang, Quynh (Fed) wrote:
> 
> Rekeying too often than needed would just create more room for
> issues for the connection/session without gaining any additional
> practical security at all.

With regards to rekeying frequency I'm concerned about testability,
have it to be too rare and it is pretty much as good as nonexistent.

This is the reason why I set the rekey limit to 2M(!) records in
btls (with first rekey at 1k(!) records). These limits have absolutely
nothing to do with any sort of cryptographic reasoning[1][2].




[1] If they did, then Chacha rekey limit would be when RSN exhaustion
is imminent (since RSNs can't wrap, but can be reset). 

[2] The 2M limit is chosen so that it is reached in ~1minute in fast
transfer tests.


-Ilari