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

"Dang, Quynh (Fed)" <> Fri, 10 February 2017 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDEED12956D for <>; Fri, 10 Feb 2017 10:56:41 -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 BZ87KxppWKa6 for <>; Fri, 10 Feb 2017 10:56:40 -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 2F027129AA2 for <>; Fri, 10 Feb 2017 10:56:39 -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=0+sLTh04fK1cyaZhIJisGeM0u/+qNgKrsCb5IHXD3Ac=; b=0IT/dlgl9GlRlFeo0aSPWdxm8py6NXIldW4x9u781GCXT1QHfP5T6ih1GoSD5zhmTLZlsbtOasHw225YftpCzDUKrTRhCpEkuKRI1akor6c1LFgsxjasR59gQf3vycvy+IzW00bZDfzbRUdIVSrxnx7WsoVa5gNNiBMnHEoPwqg=
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 18:56:37 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 18:56:36 +0000
From: "Dang, Quynh (Fed)" <>
To: "Paterson, Kenny" <>, "Dang, Quynh (Fed)" <>, Sean Turner <>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg5wBoDZYWLM7Y0meekq7MUVdlqFifU4A///GdAA=
Date: Fri, 10 Feb 2017 18:56:36 +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-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:DhTKf2QAA3QnW4l7eidfclmEg7si5fgLD5l/CCGf3XSZ9TX6UfwGKHJp0Knyv9EJ0VItzxiPqqm0r6+lGx0gapH+Z6hq9Odcpqop8dsDBpF1Pn5jQYGqMYUlZ5cMhrnxbGiKMxonDeYfr0YwJPV2saWviL9xjrjPYoEbT5esDm/K01hca59eUjabtYpasv0mA0AB0bWEykHeUTCfmBvtUhLHxZG/Yv0/jDBUUqYeIO5Xq5OBvx3tOiFoIWzZ33W3u3v00gZh195Ad1199epovHXgckcdQDJUTcrT7loOKw7TkhQgbS2xRTtXDG2idJK9BbA4jrlzholBrLDeF107PkbtHrIzNTWcWxpns9Sqz0Kc15mjq8qg3Ia/7Q3oem402lFfQCxn7x1gCa9jAPY9jw5291ZHn9Vuh5U1pIv6ImBBF2iKvudVzzRmWoTaRAXEwy9VNUpaOWOpjsypoeE3L/xS0Fe0VwZ+VF+XpGHbr+yv4G3e5A4UUusyb4bz7vIr3p3y1jvQ3uhQ4v3d19auYw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(377454003)(24454002)(199003)(189002)(101416001)(6306002)(236005)(54906002)(6512007)(54896002)(99286003)(97736004)(77096006)(6486002)(93886004)(6506006)(229853002)(6436002)(7736002)(83506001)(86362001)(606005)(68736007)(7906003)(25786008)(8656002)(122556002)(36756003)(50986999)(53936002)(8676002)(81166006)(5660300001)(2900100001)(2906002)(8936002)(102836003)(4326007)(81156014)(2950100002)(966004)(6116002)(3280700002)(3846002)(4001350100001)(66066001)(76176999)(54356999)(3660700001)(92566002)(106116001)(38730400002)(105586002)(106356001)(53546003)(6246003)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: 866149e0-fbde-4faa-2d93-08d451e68a34
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462;
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)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462;
x-forefront-prvs: 0214EB3F68
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D4C375192F85Fqdangnistgov_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 18:56:36.7844 (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: <>
Cc: 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: Fri, 10 Feb 2017 18:56:42 -0000

Dear Kenny,

From: "Paterson, Kenny" <<>>
Date: Friday, February 10, 2017 at 12:22 PM
To: 'Quynh' <<>>, Sean Turner <<>>
Cc: IRTF CFRG <<>>, "<<>>" <<>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear Quynh,

On 10/02/2017 12:48, "Dang, Quynh (Fed)" <<>> wrote:

Hi Kenny,


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

My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
being a counter-mode encryption and each counter is a 96-bit nonce ||
32-bit counter. I don’t know if there is another kind of proof that is
more precise than that.

Thanks for explaining. I think, then, that what you are doing is (in
effect) accounting for the PRP/PRF switching lemma that is used (in a
standard way) as part of the IND-CPA security proof of AES-GCM. One can
obtain a greater degree of precision by using the proven bounds for
IND-CPA security of AES-GCM. These incorporate the "security loss" coming
from the PRP/PRF switching lemma. The current best form of these bounds is
due to Iwata et al.. This is precisely what we analyse in the note at - specifically, see
equations (5) - (7) on page 6 of that note.

I reviewed the paper more than once. I highly value the work. I suggested to reference  your paper in the text.  I think the result in your paper is the same with what is being suggested when the collision probability allowed is 2^(-32).