IETF Logo Mail Archive

[TLS] 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> Sun, 13 November 2016 20:48 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 CBD9F1294E2; Sun, 13 Nov 2016 12:48:39 -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 s7le50TVBkkN; Sun, 13 Nov 2016 12:48:34 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0095.outbound.protection.outlook.com [23.103.200.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA87F12948C; Sun, 13 Nov 2016 12:48:34 -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=irrD92n09SFOUJgESsjYqQfKFxPslF99y57dBTw0jrM=; b=lBjtut3Wkb2f28gewXucs10BEvkIxohj6Zk6LJxNp9hMXqKg0vtpN6kXJsITTfOR0ASOoUmHusecaC+J5PtInOBhk8kRXgxaj5qD/5AbRuEdFPYUEaBZkfhaNQxQEe4qrfqFJWNyvJ0oAIlv/WVWbdForMcdD48b7dRa8gr1bAc=
Received: from DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) by DM5PR09MB1466.namprd09.prod.outlook.com (10.173.171.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sun, 13 Nov 2016 20:48:33 +0000
Received: from DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) by DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) with mapi id 15.01.0721.015; Sun, 13 Nov 2016 20:48:33 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: "ekr@rtfm.com" <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5
Thread-Index: AQHSPe67hB6sb8v2EES9vmvjfbAsXg==
Date: Sun, 13 Nov 2016 20:48:33 +0000
Message-ID: <DM5PR09MB1467742B07519F09EE8FA0B2F3BD0@DM5PR09MB1467.namprd09.prod.outlook.com>
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: [2001:67c:370:144:6444:b25c:b655:6dbc]
x-microsoft-exchange-diagnostics: 1; DM5PR09MB1466; 7:nWYrY2dyIxWpBqMTdSmTS7dgbuH7tgNSe99nWr5GX5/yonxxMREx9EMw13mweOtSeqkbPK57BT2yUyLwMJDZRPabQMT55bwJPOCdHNt3Dfnn2L2d9FY0Ug3bGea4y3Eyfo7bl8M1Zy9Q7VQX9glDJzXXz48am3k94GRjXhqS2qpQ50GNQUGt3eEw8GPV0TwBakp46ZYtL49dy01Scm0WyKQu5mZrPpbIJsFH+zS2+Frz0jZRvz/Pi6ohJduTTUnzd2ugZCnZqa+7fzQBSOdhHVfSK0D+M6hrLJmamPCWgSfceKug+tqpDTy+Xbsg2QLm8/jiZF6OsiojQv5hCALiRwog+G7n5ZkWMO5TfNQGVuk=
x-ms-office365-filtering-correlation-id: 8231d193-22b3-4d01-a2f7-08d40c066ea7
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR09MB1466;
x-microsoft-antispam-prvs: <DM5PR09MB1466ED2AA2F1CDE1300C871CF3BD0@DM5PR09MB1466.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM5PR09MB1466; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1466;
x-forefront-prvs: 012570D5A0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(336003)(199003)(189002)(2900100001)(92566002)(6606003)(9686002)(8936002)(4326007)(6116002)(81166006)(7846002)(77096005)(81156014)(5001770100001)(97736004)(102836003)(122556002)(8676002)(2906002)(19627405001)(586003)(7736002)(189998001)(76576001)(50986999)(3660700001)(106116001)(68736007)(54356999)(105586002)(33656002)(101416001)(2501003)(87936001)(106356001)(99286002)(5660300001)(7696004)(74316002)(3280700002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1466; H:DM5PR09MB1467.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_DM5PR09MB1467742B07519F09EE8FA0B2F3BD0DM5PR09MB1467namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 20:48:33.0408 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1466
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OB47E9Qltiry2e5ec0sjskkn-1I>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: [TLS] 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: Sun, 13 Nov 2016 20:48:40 -0000

Hi Eric and all,

Regardless of the actual record size, each 128-bit block encryption is performed with a unique 128-bit counter which is formed by the 96-bit IV and the 32-bit counter_block value called CB in NIST SP 800-38D under a given key as long as the number of encrypted records is not more than 2^64.

Assuming a user would like to limit the probability of a collision among 128-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext ( or plaintext) is 2^(96/2) (= 2^48) 128-bit blocks which is 2^64 bytes.

Reading the 2nd paragraph of section 5.5, a user might feel that he/she needs to rekey a lot more quicker than he/she needs. Putting an unnecessarily low data limit of 2^24.5 full-size records (2^38.5 bytes) also creates an incorrect negative impression (in my opinion) about GCM.

I would like to request the working group to consider to revise the text.

Regards,
Quynh.

v2.23.0 | Report a Bug | By Email