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

"Paterson, Kenny" <> Fri, 10 February 2017 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EF54129A61 for <>; Fri, 10 Feb 2017 09:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 Iw470sKT_57K for <>; Fri, 10 Feb 2017 09:22:36 -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 CA0BE129A69 for <>; Fri, 10 Feb 2017 09:22:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n/LRRwKHM6QBMFVVxjJ/3tsQYtdVZW9VtPZJT7oHpzM=; b=p4tyD2Vw7s451TZtqhgKEy4r+cryOi4dEyOCAEJcZQAG4T52vyJwg4pGutO4WBbk4VS1sZpmlaGjcl0csnFplHQx3PBTqWh0UBTevZIIRmHwDTwD1PsCi5agOF9gYjU66ApM5svTxBHk17tk/R3AyINswRh221sqVcXU6Xe4Ju8=
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 17:22:33 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 17:22:33 +0000
From: "Paterson, Kenny" <>
To: "Dang, Quynh (Fed)" <>, Sean Turner <>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ulN42j3rwAVkipPJ3aFAzvI6FhuukAgAA4koCAAD3QgIAATPYA
Date: Fri, 10 Feb 2017 17:22:32 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, 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; AM4PR0301MB1907; 7:pmFdocvmAxGE4SFBIix1OWUiObAnRMVo5ClVojqetHA+H9RosZ+yrvdXiIRlKDTRP/Nn+CpfFf/OOTX/v+1fEQTl5jIIU5wzu9u/nGECg8yCvGfbZH/T+LX9F6wTcCSniyToYQnXY+tzMh4Z6kYUoYqNuwOTyd326LD4xr3sQHz13Ybu9cEQSHm7EJSV7JhfVYULtK+BTLjKb1t6xc/oMv/uRz57bfpiVBLki5KA8ZZwCFjS6Ck658jGiyfk6I2l+AHPDELPSfdUaFhbbrwJsnyXO8QngzHfIfochof0iMeYQOhMQmgzlWB+FDcKlQcZb8t+oM9GWkiyQN/T5sIKd30Atr/bd9OAECbHFP3l0PEEdo8t28nva6DBKxx+w/edLkaQoWKQ4rAKM36gj4B6vwNOinfRB+RtXClhKSng2OnpTIlvzSQTK2nyhbQ89y25AviVVjp6ie2TwW4mRGCH2KeiZZwBiA+lnS0+xoU/i/ki2hAT0t+RQQKSLcJZWes9cYd64OkgL/6bgM00WHz9/Q==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(53546003)(8656002)(966004)(6246003)(5660300001)(81156014)(53936002)(8676002)(229853002)(3846002)(66066001)(7736002)(6116002)(102836003)(92566002)(83506001)(25786008)(189998001)(38730400002)(305945005)(6306002)(97736004)(6512007)(6436002)(54356999)(3280700002)(99286003)(2900100001)(54906002)(81166006)(76176999)(6506006)(77096006)(50986999)(3660700001)(4001350100001)(6486002)(8936002)(101416001)(2950100002)(106116001)(106356001)(42882006)(93886004)(86362001)(36756003)(68736007)(105586002)(2906002)(74482002)(122556002)(4326007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 5890bdce-02e8-42b5-84c0-08d451d96641
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1907;
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)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1907;
x-forefront-prvs: 0214EB3F68
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 17:22:32.9273 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907
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 17:22:45 -0000

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.