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

"Dang, Quynh (Fed)" <> Tue, 14 February 2017 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BA27129784 for <>; Tue, 14 Feb 2017 10:46:02 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h1xPdfx_qt9h for <>; Tue, 14 Feb 2017 10:45:57 -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 36686129570 for <>; Tue, 14 Feb 2017 10:45:57 -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=GB8P4EGPA4wHJUW0kCgbiUaObJD0uDz8pq0+phIcr1g=; b=u8/5GPv5ShDWD6Vm2J4vUihe6gQXo0NqqNV0mtrNQyMU/EzukDHf3AsWfsPTWNxRy/yPD9KG6+JtnNRMbGFa8TnsZPGG9XKfy0pA11spPyR6uCljzyqcLXM3X2CLa5149oySBEj18bvkxWxQuQ3he8sdG1FXUCgOTRzqtzxrVFc=
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; Tue, 14 Feb 2017 18:45:55 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 18:45:55 +0000
From: "Dang, Quynh (Fed)" <>
To: Sean Turner <>, "" <>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QAgACb9ID//85ZAIAAVXBE
Date: Tue, 14 Feb 2017 18:45:55 +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: 03ac788c-a2f2-4f66-a5c6-08d45509b58f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:Bdtr1r5qlT1s7JX8f2rXc8cvJ/qbU7qiZNHejaB1z94MpqUq3+a7Z6fiB7zySi4CqzkZSzTisw+GG51eGm3mR6jlkWVeY26Coot1HoYL/7ooh8n43sXXqQ/GgUjntL7N3POrU+XZqn6iHfvIrM4dz5Dj65irp4lCHhQhp1r6faRVMBouAh/w2k3QIMlUk5DrLN66lX2JPphvD7n0sKmzUWBKvQB59GYLnkvfI4GUoGQ4SU0+3WNDuYVm7dtmwPt5NHj+uqxOL1Kw3xlzeVn52AS9E+sCpdvxuuI/POz1zZb8GiRVnbiWxs1ABpnbBcBdBk+ADJ89HbV+I7CDQo4k6yw1VEW44In2Qu/bAU8JGUtZyvbMvKM149hLCDMKWpUyFdRbG+Y8iTMR00HDZC+FaXevZGlaXV2lLqeCdGMC11xlnvkrJHFDBzfaQGvGWqgZLs8NWnMMMggB2jB+H1oYtJSjg59shQnyJPGIS0oW19plGFgu/KR6zyZjRE+gr3al6yBOWD7whvYKFMBGjvgNJQ==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462;
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(24454002)(377424004)(377454003)(199003)(189002)(106116001)(6436002)(54896002)(105586002)(6506006)(106356001)(229853002)(19627405001)(122556002)(6306002)(9686003)(236005)(2501003)(77096006)(99286003)(33656002)(81003)(55016002)(25786008)(68736007)(3660700001)(6246003)(53546003)(189998001)(81166006)(2900100001)(5660300001)(606005)(38730400002)(7696004)(4326007)(102836003)(86362001)(6116002)(2950100002)(53936002)(3280700002)(93886004)(3846002)(74316002)(101416001)(8936002)(7906003)(66066001)(7736002)(2906002)(54356999)(92566002)(81156014)(76176999)(97736004)(8676002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462;; 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_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 18:45:55.2346 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462
Archived-At: <>
Subject: Re: [Cfrg] [TLS] 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: Tue, 14 Feb 2017 18:46:02 -0000

Hi Sean and all,

Beside my suggestion at, I have a second suggestion below.

Just replacing this sentence: "

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) security.

" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial or full) input blocks may be encrypted with one key. For other suggestions and analysis, see the referred paper above."



From: Dang, Quynh (Fed)
Sent: Tuesday, February 14, 2017 1:20:12 PM
To: Atul Luykx; Dang, Quynh (Fed)
Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG;
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Atul,

From: Atul Luykx <<>>
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' <<>>
Cc: Markulf Kohlweiss <<>>, Antoine Delignat-Lavaud <<>>, IRTF CFRG <<>>, "<>" <<>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hey Quynh,

When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext
pairs available to the adversary, it will still take roughly 2^128
operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: just one ciphertext block.

This contrasts with any mode of
operation, where adversarial success probability increases according to
the amount of data available and the computational complexity required
to perform such an attack is not the limiting factor (which is the core
of the problem we're discussing right now).

IND-CPA is important. That is why I have always been supporting it. Data is equivalent to computation in the sense that data are produced by computation. 2^x blocks = 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). And, 1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.


Regardless, correct me if I'm wrong Quynh, but you seem to have two
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of
caution instead of recommending that people switch when adversaries have
success probability 2^{-32}. I don't see the discussion progressing on
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' <<>>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss <<>>, "Paterson, Kenny"
<<>>, Sean Turner <<>>
Cc: Antoine Delignat-Lavaud <<>>, IRTF CFRG
<<>>, "<<>>" <<>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won’t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
From: TLS <<>> on behalf of Markulf Kohlweiss
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" <<>>, Sean Turner
Cc: Antoine Delignat-Lavaud <<>>, IRTF CFRG
<<>>, "<<>>" <<>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)
Our analysis of miTLS also supports option a)
A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.
When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
Also, many users don’t know what “confidentiality bound” means.
The current text Eric wrote talks about a number 2^24.5 of full-size
records. In many situations, the record sizes are not full size, but
different sizes. My latest suggestion text does not assume full size
records, it covers variable record sizes, it just counts AES-input
blocks or AES operations.
We verified an implementation of the TLS 1.3 record
(, to appear at Security & Privacy
2017) where we arrive at a combined bound for authenticity and
confidentiality that is compatible with the Iwata et al. bound.
Markulf (for the miTLS team)
My preference is to go with the existing text, option a).
>From the github discussion, I think option c) involves a less
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should
aware of the weaker security guarantees it provides.
I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
for AES-GCM.
On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
<cfrg-bounces at on behalf of martin.thomson at>
On 10 February 2017 at 16:07, Sean Turner <sean at> wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]
a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).
I could live with c, but I'm opposed to b. It just doesn't make
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.
Cfrg mailing list
Cfrg at
TLS mailing list<>
TLS mailing list<>