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

"Dang, Quynh (Fed)" <> Fri, 10 February 2017 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7ABA31295B2 for <>; Fri, 10 Feb 2017 04:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F_OaSkNUf71g for <>; Fri, 10 Feb 2017 04:38:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95E86129613 for <>; Fri, 10 Feb 2017 04:38:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FgRpksH1PX5jNzPkwBaheUWRuxHGFvtj8oE+6jvC41Y=; b=v7dugR6zuCShPGLspiMWxw+JdzjcSELC9MPqIVcCQPnzt3LL3hJIpdYW5ARXbfAHrBInDTJZr7Ai2u+Ug4vhfPyNpFSD/w2nxanRLmunjTYNh/MrKTjc18EgYwUKtaL/Inmu+qvfwnWLv+VUIWmfw1XneipJlv01jGO+Morr4p8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 12:38:35 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 12:38:35 +0000
From: "Dang, Quynh (Fed)" <>
To: Sean Turner <>, "<>" <>
Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ujO2IdKSxzmEyFi9zUyMXxM6FiINGq
Date: Fri, 10 Feb 2017 12:38:34 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 7cf13fea-527e-4362-0fc3-08d451b1bac0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:Hq/mF2Aq8CpakIfcCLl18q0Wk1cJdXc+EwjKT0ZzUTGubGBubzGRoYYCZH1uObQ/Lhz5I/g0ZbG2tlaVEkSx0z4bbzmxHnIoljKoWSSzqYBcJEvpwyZPJRaYSHtF3I89BlPgAtWHT3PM/NEJTJsu1hTFcWsvl9Xg2MCrBbBUwmg8+iyj3CUXJt6zYjfo5K9TUkMc8c26I66MU595z86jiwd5qlEL/VnBToQlPMI4vOYDccX/WYHSSaeGiOunCmuR+56N/BJDMfOYemK46jDkdyhSj5UUIq2RkQIzW1gQy/gh9FvjIt13vS48JWiZbt8r/aoJzLphtWTj0bQH230zthKMigCostYuoHZQX4EyRPCmVwwq+6XmajiyBCoyUywHetfEXPOkGV8z7NPI3DHz245TyFMvRpVq0+613Rzpj1B6PjWwrUjlXr6oo0vr7w/CMosKYDwX1fF6O1H8Dl4wUBaJqI1QZefzxkByq+ZMPCpyCEtZMtmzJi3BDtwxEk4dwtJvOuuufGzZKuVFsIkbMQ==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39410400002)(39450400003)(199003)(377454003)(189002)(6116002)(54356999)(76176999)(3660700001)(50986999)(92566002)(25786008)(53936002)(74316002)(2950100002)(6436002)(55016002)(54896002)(606005)(3280700002)(77096006)(7906003)(9686003)(6306002)(3846002)(6506006)(81156014)(5660300001)(8676002)(101416001)(122556002)(81166006)(8936002)(7736002)(33656002)(4326007)(7696004)(102836003)(86362001)(97736004)(236005)(66066001)(2900100001)(68736007)(229853002)(99286003)(106356001)(189998001)(106116001)(38730400002)(105586002)(6246003)(53546003)(2906002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 12:38:34.8621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464
Archived-At: <>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Feb 2017 12:38:39 -0000

Hi Sean and all,

I agree with everyone that the text in (b) was not very good text.

The problem with (c) is that it is not precise at places and it leaves out a lot of informative discussions which users should know.

The sentence "The maximum amount of plaintext data that can be safely encrypted with  AES-GCM in a session is 2^48 128-bit blocks (2^52 bytes), assuming  probability of success at 1/2^32" is not clear.  What is the success here? And, with 2^48 (full or partial) blocks, the collision probability is below (not at) 2^(-32).

And, "safely encrypted", what does this mean? I would like not having a collision among 128-bit blocks of ciphertexts, but I dont see any damage to the data owner who sends the encrypted data over a TLS session.

I copied the text that I later proposed under the discussion of PR#769 below.

" To use AES-GCM to provide authenticity of authenticated data, confidentiality of plaintext content, and information leakage [0] protection for the plaintext safely, the limit of total ciphertext under a single key is ( (TLSCipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 128-bit blocks.

When the data limit is reached, the chance of having a collision among 128-bit blocks of the ciphertext is below 2^(-32) which is negligible.

Since the block size of AES is 128 bits, there will be collisions among different sets of ciphertext from multiple sessions using GCM (or any other modes of AES) when the total amount of the ciphertext of all considered sessions is more than 2^64 128-bit blocks. This fact does not seem to create a practical security weakness of using AES GCM.

For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached. See [AEAD-LIMITS] for further analysis.

[0]: Information leakage in the context of TLS is a chosen-plaintext distinguishing attack where the attacker provides 2 128-bit plaintext blocks to a GCM encryption engine, after seeing one encrypted block for one of the 2 plaintext blocks, the attacker knows which plaintext block was encrypted. Or, it means that there is a collision among 128-bit blocks of the ciphertext. "

  1.  The text above uses blocks instead of bytes or records of ciphertext.
  2.  The partial block situation is taken into account.


Or, using good text from PR769 provided by brainhub, the first paragraph could be replaced by the following.

"To use AES-GCM to provide authenticity of authenticated data, confidentiality of plaintext content, and information leakage [0] protection for the plaintext, the limit of total ciphertext under a single key is 2^48 128-bit blocks with the ciphertext size being rounded up to the next 16-byte boundary. "



From: Cfrg <> on behalf of Sean Turner <>
Sent: Friday, February 10, 2017 12:07:35 AM
To: <>
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)


We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).


Cfrg mailing list