IETF Logo Mail Archive

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

"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Mon, 21 November 2016 23:02 UTC

Return-Path: <quynh.dang@nist.gov>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB321293E4; Mon, 21 Nov 2016 15:02:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com
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 V5glUs3d1KdA; Mon, 21 Nov 2016 15:02:01 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0094.outbound.protection.outlook.com [23.103.200.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE8F1294E8; Mon, 21 Nov 2016 15:02:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OTwhLGIm7WCd355VH/CQ4y8u1vCFrAU1uH44r4psE/s=; b=LT8cf8HE7hYg80DFhOIj3hWFTuY/NZDzAXOq8PyAxGiX+kD5MZ6mNar5DMsZsRQ+LniADfSrkPD+IQIUfaIa3m2Y6d/PmNVHUSIXvJ3ZsfQvUCFhHl+HzLzwVtKj7cBUaxdESw3uBavsbGzOOl3JSwBVeBoCTSrZ5OWSeN5i2Xc=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Mon, 21 Nov 2016 23:01:59 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0734.013; Mon, 21 Nov 2016 23:01:59 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Thread-Topic: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5
Thread-Index: AQHSPe67hB6sb8v2EES9vmvjfbAsXqDXlqSAgAAv0JWADC09gIAAJjCn
Date: Mon, 21 Nov 2016 23:01:59 +0000
Message-ID: <CY4PR09MB14646C5559950CDF77AA665AF3B50@CY4PR09MB1464.namprd09.prod.outlook.com>
References: <DM5PR09MB1467742B07519F09EE8FA0B2F3BD0@DM5PR09MB1467.namprd09.prod.outlook.com> <CABkgnnVS5rTnoGHs1fxAy2eBrCKerZbQmLNzzrhKBm4eiHhceQ@mail.gmail.com> <DM5PR09MB14673CCBCDC107D5912F8669F3BC0@DM5PR09MB1467.namprd09.prod.outlook.com>, <20161121204231.GA9484@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20161121204231.GA9484@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.222.56]
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:Ng8lLxIH7x/ixDqjUj6mzoZ3u1FYGEax+p7ZwERoIf6KZwIv67CGbLF6+mNqkVqyBMXGdUBW9iD18G1G9CDPVbgVzv28B2hHcpp8XQg3B4gRHqFjTOxjvVqcTuM128l0Y/ej+OKfFzlp+L1AVQ59X1nTtGcn1lJW7otbNDxU6ciYYpTFannBtHjonHf+U0bmXkGPrk+WRAiFitInhfvN8zHWjeeB4ng+4Cih+hXWzYFIqLS17H6bKeYuCG9QoUt6IcCRP8L+VSXarkp8kN8NG9ng1r/k85VqhmyTZ7rzVGToINnMgp5n4huUVlhsv8sZpMA8oCE3Wf8P7oExvpJl/YdElPIa4a87DF6QNrsOc/8=
x-ms-office365-filtering-correlation-id: 7caf4f19-b88a-4e69-683f-08d412626611
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR09MB1461;
x-microsoft-antispam-prvs: <CY4PR09MB1461725439B6BE86C44EB608F3B50@CY4PR09MB1461.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(6061324)(6072148)(6042181); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461;
x-forefront-prvs: 01334458E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(189998001)(5660300001)(7696004)(229853002)(66066001)(92566002)(54356999)(50986999)(76176999)(101416001)(33656002)(76576001)(3660700001)(3280700002)(2906002)(87936001)(9686002)(106356001)(4326007)(6606003)(7736002)(2950100002)(8936002)(74316002)(7846002)(106116001)(97736004)(6916009)(77096005)(105586002)(68736007)(8676002)(122556002)(99286002)(81156014)(110136003)(19627405001)(6116002)(2900100001)(86362001)(93886004)(102836003)(6506003)(3846002)(38730400001)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB14646C5559950CDF77AA665AF3B50CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2016 23:01:59.3533 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/s8dnOwI3B09FY05xuoWLm_VtrY4>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 21 Nov 2016 23:02:04 -0000

Hi Ilari,


You were right, for testing, a smaller number should be used.


Quynh.




________________________________
From: ilariliusvaara@welho.com <ilariliusvaara@welho.com> on behalf of Ilari Liusvaara <ilariliusvaara@welho.com>
Sent: Monday, November 21, 2016 3:42 PM
To: Dang, Quynh (Fed)
Cc: Martin Thomson; tls@ietf.org; cfrg@ietf.org
Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5

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

v2.23.0 | Report a Bug | By Email