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

"Dang, Quynh (Fed)" <> Tue, 14 February 2017 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E3A71295DF for <>; Tue, 14 Feb 2017 03:59:49 -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 b0x0Q31-MEhU for <>; Tue, 14 Feb 2017 03:59:46 -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 7932F1295CB for <>; Tue, 14 Feb 2017 03:59:46 -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=alcX0Sue+kyVeLg++Kbn9+lHWiS7nMrDsfnFJqvGnWs=; b=VtcukwHUtShAEMLFvUWzsivKpISmyu9rt7sqUtDCNtEVmsVPYua796Tw0Oe8r71oY8gbyBtbyRst5BcIc6B74+BqjXAhZXTa9bFdtlOKnqDVL/99xwNW+yuQ51b4v1DCHqlA+LvvOFwyzP9c8oAz6fehu6GElYCeamGbS9qTvzc=
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 11:59:44 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 11:59:44 +0000
From: "Dang, Quynh (Fed)" <>
To: Markulf Kohlweiss <>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QA
Date: Tue, 14 Feb 2017 11:59:44 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: f39056d9-01a3-4057-155b-08d454d0f750
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:xBVGsHpvfGScMXbWYdBYDU2scucR4JPkNGHIGgsO9oFQjnEL8s5+B2LZ4YrA6o7DxwL5cotuWuSgEF6Vr+m819Bwl+WHQZdiG5VY9vkS+5UBvhcu20LdTDMc8+q1L6Fcze1XEU5xH06yJJu7rIU+w7AL9D0KOaNK2CnGsqNc4JapmcIIYloRW9XvJlZ7IZMsL94CAaNsh7gp6M/eui+lbH++dOFCNiuQtkcOiJaYuaqX7Y1qDZLZwLCtjpouZ+X2stZNjRrh1s1UUtK/Mjdh9Ycr5aMpv3GKN02rVNs/gEAAbDFgYiWaDh+8mb5MFCgCbFivCphoXzryJUaNdRy0tDHDyv5DsgjTaq7mtW7ADSmwJF7k+u/BHyuDcEeSkbQMW5/DAVgTgC60lEoHR2aIYNAJ07qfB4g+UdJk/YkvnI5NHRNIUVpOXuyZ63e5ZrdVQX73aZ6Endh99lVvqP88n12pZmLOeM5Z/tGUnjuS0P2gGBAeEre+6aJUBZzDg/6+pN9dYIdJRQPEOmGsdDRy7Q==
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)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461;
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39410400002)(39450400003)(39860400002)(377454003)(24454002)(199003)(189002)(229853002)(50986999)(101416001)(99286003)(54906002)(54356999)(76176999)(189998001)(93886004)(53936002)(36756003)(86362001)(3846002)(6116002)(8676002)(106116001)(102836003)(2906002)(3280700002)(81156014)(81166006)(92566002)(106356001)(606005)(6246003)(54896002)(122556002)(8936002)(3660700001)(6306002)(236005)(2421001)(4001350100001)(105586002)(66066001)(6512007)(4326007)(25786008)(2561002)(77096006)(6486002)(6436002)(7736002)(1511001)(83506001)(68736007)(2950100002)(6506006)(6916009)(8666007)(2900100001)(81003)(38730400002)(53546003)(110136004)(5660300001)(7906003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461;; 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_D4C850542FDA4qdangnistgov_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 11:59:44.3692 (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: <>
Cc: Antoine Delignat-Lavaud <>, IRTF CFRG <>, "<>" <>
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 11:59:49 -0000

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 (#765/#769)

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 blocks.


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  2^(-28).

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 zero.

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 conservative
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 be
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 proof
for AES-GCM.



On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
<cfrg-bounces at on behalf of martin.thomson at> wrote:

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 sense.
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<>