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

Aaron Zauner <azet@azet.org> Thu, 16 February 2017 19:51 UTC

Return-Path: <azet@azet.org>
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 591081294A5 for <cfrg@ietfa.amsl.com>; Thu, 16 Feb 2017 11:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org
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 U0zAj51K7FsT for <cfrg@ietfa.amsl.com>; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B021129470 for <cfrg@irtf.org>; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id i10so18852777wrb.0 for <cfrg@irtf.org>; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=RP4xmjiRaKg7T4jJ97gb2pPn4Ltw9WKeNIyOX3mryIg=; b=Af4dCvKReirZmYe9Qg7O37V4D39sHCQ6eGwmA+sD6v1px8L4p6R1GJpzPF3r9zvr0t SOqW22TOQboo8oISjcYbJ3wke0cY+XFGK2ROQ67OSNfZoroqxT0OZQ8amvuoz36L9aEw NXxy7Mtdc9T6++Xjz5PSzaVFnFAUUdwv7+2Tc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=RP4xmjiRaKg7T4jJ97gb2pPn4Ltw9WKeNIyOX3mryIg=; b=NQzOqRlcHzGMjD+BycWXAHAglNv7s2Qhj9XsVBu08DNgg1U26thdTxrGBVBU4i1qyv dD1GGBgA+O2/sKTG+tC9Ygmno+VVxWAEmxxWud63q3iQ9t5ztXsmhwSS63vhdMyN3bpV MKPuIQr7GVpK3g0qBVuTpLWgkR/xnmMOfcV2ppf/XlI05vjnuqIO4WmnPw6ZLT2ClB5d bZAghFjDV/Kge00QnmrlHOZr7SQqCuAEoOv6EBBOlKm+1QlBulIIOiFB4ixEVohUa8wZ ovLBjJX37tA+CUgUZiCx42O/A19BFDQa1HWGvdSEyMUCMPMcHAizjWFybZ0ADj2SWqec DE3g==
X-Gm-Message-State: AMke39lvkhVmPkSmJ1gzoQkkMklUY3GNjbE0dQZ18C49PdJ2+ZUIem5n9FLlHJpW0jvF7Q==
X-Received: by 10.223.179.87 with SMTP id k23mr4226551wrd.32.1487274686969; Thu, 16 Feb 2017 11:51:26 -0800 (PST)
Received: from [192.168.1.120] ([156.218.58.77]) by smtp.gmail.com with ESMTPSA id c202sm1492730wmd.10.2017.02.16.11.51.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 11:51:26 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner <azet@azet.org>
In-Reply-To: <D4CAF736.3040C%qdang@nist.gov>
Date: Thu, 16 Feb 2017 21:51:22 +0200
Message-Id: <8EEF5E9A-FFCD-44F9-9A68-920EDC4C9FA7@azet.org>
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> <CDDC7812-27AF-4566-AE33-6DF829FEB81E@rhul.ac.uk> <D4CAF736.3040C%qdang@nist.gov>
To: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/L-MvL4Ut_6OHxvbbvdGNW2nAuBU>
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: Thu, 16 Feb 2017 19:51:30 -0000

> On 16 Feb 2017, at 14:23, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
> 
> Hi Kenny,
> 
> I am glad to see that you enjoyed the discussion more than what you planed for the time on your vacation.  We love crypto and the IETF!
> 
> From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
> Date: Wednesday, February 15, 2017 at 8:46 AM
> To: 'Quynh' <Quynh.Dang@nist.gov>
> Cc: Atul Luykx <Atul.Luykx@esat.kuleuven.be>be>, Yoav Nir <ynir.ietf@gmail.com>om>, IRTF CFRG <cfrg@irtf.org>rg>, "tls@ietf.org" <tls@ietf.org>
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
> 
>> 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> wrote:
>> 
>>> Hi Atul,
>>> 
>>> I hope you had a happy Valentine!
>>> 
>>> From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>
>>> Date: Tuesday, February 14, 2017 at 4:52 PM
>>> To: Yoav Nir <ynir.ietf@gmail.com>
>>> Cc: 'Quynh' <Quynh.Dang@nist.gov>ov>, IRTF CFRG <cfrg@irtf.org>rg>, "tls@ietf.org" <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.
> 
> As far as I know, such chance has not happened in history for any targeted search where the chance for hitting the target is 1 in 2^32.
> 
>> 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 described my point not in a best way, sorry. For key recovery, if an attacker can do 2^96 AES operations, his chance of finding the key is 2^-32, but this chance will get improved if the attacker does more computation. On the contrary, the chance for the distinguishing attack won’t change with the proposed data limit.

Maybe I don't comprehend what you're trying to propose - but why change this paragraph then?

Coming from an HPC background: It seems to be that with frequent rekeying the chance of successfully performing an exhaustive search attack is -- even for the most advanced adversary -- so slim that we do not need to worry about that. In reality this is a cost-for-computation tradeoff that no one is going to invest in if there're more practical ways to attack (e.g. HUMINT/bad OPSEC, steal a private key, intrude a given network etc.) given the resources and thus money/power needed.

> 
>> 
>>> 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.
> 
> I just checked the paper. There is a small error I think. AES-GCM in TLS 1.3 is a prf. Under a given key, every input block or just one repeated block 2^35 times, their ciphertext blocks are 2^35 random 128-bit blocks assuming the key has 128 bits of entropy. If there is a collision among the ciphertext blocks, it does not mean anything because it does not say anything about the plaintext blocks.
> 
> 
>> 
>> 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.)
> 
> I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 are all safe choices. If someone wants to rekey sooner (or often) for operational reason or any other reason, that would be just fine. I just hope that we don’t have text which might imply that 2^-32 is not a safe choice.  In our guidelines, we basically indicate that 2^-32 or below is safe.

...

> 
> 
>> 
>>> 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
> 
> I am going to propose another option and I hope that you and all other people will be happy with.

I'd strongly suggest that any changes made to this text are as clear as possible to non-mathematicians/cryptographers. Years of dealing with TLS implementation and protocol vulnerabilities tell us that uncertain wording and missing, clear, explanation for certain choices in standards have caused real-world security problems. It seems to me that the general consensus is that option A is preferable anyhow.

Aaron