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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 15 February 2017 13:46 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76631295E8 for <cfrg@ietfa.amsl.com>; Wed, 15 Feb 2017 05:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.786
X-Spam-Level:
X-Spam-Status: No, score=-3.786 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, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5sNvG2DcRzR for <cfrg@ietfa.amsl.com>; Wed, 15 Feb 2017 05:46:31 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20054.outbound.protection.outlook.com [40.107.2.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218D4127A90 for <cfrg@irtf.org>; Wed, 15 Feb 2017 05:46:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zTl04xdrJ75e17uqBfz2L0OHNo/+X6LxAHPLUiveiaw=; b=zd0dEnLK0DOkYQw8OWrhyI6fh4QFNAog+OGa7tETBqd7OTqJJKc1KA3JwLefRQiFMTz0Jkaf+B2tevNYNUlc1UsCq1gZAzQt3WM9ePxA0ZCoPp91gtQvGYQG3yf/ZapJSJV4gMXoKhp1nVh6VID7y3WxqrwjkXRImI5Ve4OhFMM=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 13:46:28 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 13:46:28 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwykYuvgBCblgkOlDzVRxLEvWqFp+0YAgAAacIA=
Date: Wed, 15 Feb 2017 13:46:28 +0000
Message-ID: <CDDC7812-27AF-4566-AE33-6DF829FEB81E@rhul.ac.uk>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <CABkgnnVrFGHe0eKREXbG_pv=y18ouopZsE2c5+Czz0HAGko6rg@mail.gmail.com> <D4C331C7.86224%kenny.paterson@rhul.ac.uk> <VI1PR8303MB0094D686941D99290BB431FCAB590@VI1PR8303MB0094.EURPRD83.prod.outlook.com> <D4C73D19.2FB4B%qdang@nist.gov> <D4C85054.2FDA4%qdang@nist.gov> <be49d59e37339cbaea8fef9bdb2a8971@esat.kuleuven.be> <D4C8AE28.30145%qdang@nist.gov> <CY4PR09MB1464278F1845979862CA9C8EF3580@CY4PR09MB1464.namprd09.prod.outlook.com> <BD6FC1F4-F2ED-46F8-9E53-862B69D9C00A@gmail.com> <e7c9bc1fb1b57333bacbe2def2687d18@esat.kuleuven.be>, <D4C9AB9C.302D5%qdang@nist.gov>
In-Reply-To: <D4C9AB9C.302D5%qdang@nist.gov>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [219.59.14.82]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:UjeNrd4xMu3XNr7jy+YyHoJM9Imrl6CNIvn3/nNbJRoRcG/Uj80nnHTU/U3d0tNEi8cYlTQ3DFpcHaNGXyn5JTGDwHu9vbWYDmdGPAJRdADLmyCylP/TTv9JZE5H3erIecEK8aTpyxPVu+m6lDqKVLGYpqqEw6V2z+9p7OF2iUk/EWqyRFjO4Sp5H0z9xuK4wlK4QAl+ivZ/mei/hztpa8rg+rXFFyxwvi4PYMsHWo4PA9bC7iPrEihV1/6bwlvkJNKS4wKpMnKJU29V4dWajhSwP5V1iJC5XlaPhzFTKK/QhOgS0CNYONDjoWAQukhfdEU1P4M9jSSjHJ2ShJ1sGiOTFNGiDW8ESgLgC2OGAX4c00qOHSyybVTKnxP9Difh0mhvhFng8R5Eoh/IPDsO1HdeJMQSvwbUW7sur/bOO/13bt/pOfDTzNXVs0Keg/n753QijrANf5y3kZHiTijfmdsr3ZrXw9dk4meDtsXlDjp+7WiIhe3VOFoCk0zsb4KCDnucJfhDEmRFMUOT2CkN4w==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(377454003)(189002)(24454002)(377424004)(199003)(6246003)(54356999)(7736002)(7906003)(106356001)(106116001)(105586002)(97736004)(101416001)(2906002)(50986999)(189998001)(74482002)(66066001)(4326007)(93886004)(33656002)(76176999)(3846002)(6116002)(102836003)(6916009)(81166006)(36756003)(2900100001)(53546003)(8936002)(8676002)(92566002)(229853002)(81156014)(38730400002)(236005)(82746002)(68736007)(83716003)(5660300001)(39060400002)(122556002)(53936002)(86362001)(54906002)(25786008)(77096006)(6512007)(2950100002)(42882006)(6436002)(8656002)(6306002)(3280700002)(6506006)(606005)(6486002)(110136004)(54896002)(389900002)(99286003)(3660700001)(104396002)(19625805005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 1c2bb23d-854c-4996-932f-08d455a90aae
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1908;
x-microsoft-antispam-prvs: <AM4PR0301MB1908E828C6D4E687F97F0E35BC5B0@AM4PR0301MB1908.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1908;
x-forefront-prvs: 021975AE46
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CDDC781227AF4566AE336DF829FEB81Erhulacuk_"
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 13:46:28.2359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/IT1IQ_nIy2IMOhYGJbMhWzEFzck>
Cc: Atul Luykx <Atul.Luykx@esat.kuleuven.be>, IRTF CFRG <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 13:46:35 -0000

Hi Quynh,

I'm meant to be on vacation, but I'm finding this on-going discussion fascinating, so I'm chipping in again.

On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>> wrote:

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx <Atul.Luykx@esat.kuleuven.be<mailto:Atul.Luykx@esat.kuleuven.be>>
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>>
Cc: 'Quynh' <Quynh.Dang@nist.gov<mailto:Quynh.Dang@nist.gov>>, IRTF CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the same: they are practically zero.

I'm not clear what you mean by "practically" here. They're clearly not the same as real numbers. And if we are being conservative about security, then the extremes in your list are a long way apart.

And, 2^-32 is an absolute chance in this case meaning that all attackers can’t improve their chance: no matter how much computational power the attacker has.

A sufficiently powerful adversary could carry out an exhaustive key search for GCM's underlying AES key. So I'm not sure what you're claiming here when you speak of "absolute chance".

I don’t understand why the number 2^-60 is your special chosen number for this ?

This is a bit subtle, but I'll try to explain in simple terms.

We can conveniently prove a bound of about this size (actually 2^-57) for INT-CTXT for a wide range of parameters covering both TLS and DTLS (where many verification failures may be permitted). Then, since we're ultimately interested in AE security, we would like to (roughly) match this for IND-CPA security, to get as good a bound as we can for AE security (the security bounds for the two notions sum to give an AE security bound - see page 2 of the "AE bounds" note).

In view of the INT-CTXT bound there's no point pushing the IND-CPA bound much lower than 2^-60 if the ultimate target is AE security. It just hurts the data limits more without significantly improving AE security.

Finally, 2^-60 is not *our* special chosen number. We wrote a note that contained a table of values, and it's worth noting that we did not make a specific recommendation in our note for which row of the table to select.

(Naturally, though, we'd like security to be as high as possible without making rekeying a frequent event. It's a continuing surprise to me that you are pushing for an option that actually reduces security when achieving higher security does not seem to cause any problems for implementors.)

In your “theory”, 2^-112 would be in “higher” security than 2^-60.

It certainly would, if it were achievable (which it is not for GCM without putting some quite extreme limits on data per key).

Cheers,

Kenny

Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>>
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
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."
Regards,
Quynh.
I like the suggestion, but I’m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
------
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls