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

Markulf Kohlweiss <> Mon, 13 February 2017 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2397112961D for <>; Mon, 13 Feb 2017 07:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JbrZtAN8VKRU for <>; Mon, 13 Feb 2017 07:34:19 -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 4FA601296D3 for <>; Mon, 13 Feb 2017 07:34:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=23HkHZCUTFwnOxgymY1McYFkhnuINf3RQvo2WVHN/Zw=; b=COtoIi2/ja2maY4SQrlTq4dvR3gbjRqmRqoEx8qh5ciZxfwu55kBBTiV8FDDeE3RRBLsNYLkbvwB+F9wL/gf0ohzc8QMgrLXGEj2xnHSBn87O8l6ygAzKFF5k/jZsgs+AVC4UMNJ4V+ru5+OjJRdiZomKZpyk39F5FvHkb2hg0Q=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.0; Mon, 13 Feb 2017 15:34:13 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 15:34:14 +0000
From: Markulf Kohlweiss <>
To: "Paterson, Kenny" <>, Sean Turner <>
Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ujogZD2gIXgUWLhmF3SGaRd6FhuukAgAA4M4CABSHOcA==
Date: Mon, 13 Feb 2017 15:34:13 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2a01:110:8012:1010::6b0]
x-ms-office365-filtering-correlation-id: b3f80bdb-6e7d-4284-eb95-08d45425c3b4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:VI1PR83MB0046;
x-microsoft-exchange-diagnostics: 1; VI1PR83MB0046; 7:F/lm1bTOHd04jyv8txdnKsrVy8KnMEw1YtKA67W4uB/x/8rX1XQXw1hGadK5+XsSf4fh9E7X1XRMwFkxTv/pHgUs5TL7B+LWOBqoJ2Y2aHVN2AgFthTV9KHh2uSfZdj3fV58MHx44XQa3PKX6fGAsD5CFha4iFJqeQJI+GCkYlsnTsh/8s7H2hOfhhzWicdvJ5BMBV90UJLqg+Xuxir2bcuuYcUyH16Gd6/R++tQ3t3pRlFsjC0t8GZeHn1bKTGUI9MEsbBKDl7gTyephEWQVFRIhRBRmjRxvsa3s+SiNe8u8PGd1nhJ1NXRLYW28P+s2kEfOkHEq7v7prKe0W3L5PRlei6xN6ISKa872nAqoAtU/bGJo6AU0eyoZ9DDstx8Tscvm2XAvhqYDj3gtP4qtZc/EaKBYAwRRRcrufVNso2+qnHdgTm8kCVE2tRMDtLSBG0lJUSuk4TBa+K7ptH37JlwDFcFFqh9Rt/PPZa+JcJgmip1zY3cj8d14CvzffiTlz+B3pRBgT2nEoYXcfi5zkqt4d2ikKj2F76zHOThXVw=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:VI1PR83MB0046; BCL:0; PCL:0; RULEID:; SRVR:VI1PR83MB0046;
x-forefront-prvs: 02176E2458
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(189002)(24454002)(199003)(8936002)(4326007)(53936002)(55016002)(9686003)(105586002)(25786008)(99286003)(8656002)(6306002)(81166006)(2906002)(54906002)(6436002)(81156014)(6246003)(92566002)(5005710100001)(33656002)(2900100001)(107886003)(10090500001)(38730400002)(189998001)(10290500002)(86612001)(86362001)(97736004)(305945005)(76176999)(3280700002)(229853002)(68736007)(101416001)(106116001)(106356001)(54356999)(8990500004)(74316002)(6116002)(102836003)(2950100002)(7696004)(7736002)(3660700001)(8676002)(122556002)(6506006)(5660300001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR83MB0046;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 15:34:13.4004 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR83MB0046
Archived-At: <>
Cc: Antoine Delignat-Lavaud <>, "" <>, IRTF CFRG <>, "<>" <>
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: Mon, 13 Feb 2017 15:34:21 -0000


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.

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