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

Martin Thomson <martin.thomson@gmail.com> Wed, 15 February 2017 17:05 UTC

Return-Path: <martin.thomson@gmail.com>
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 3099112955D for <cfrg@ietfa.amsl.com>; Wed, 15 Feb 2017 09:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qJ8HdlZTEGdO for <cfrg@ietfa.amsl.com>; Wed, 15 Feb 2017 09:05:15 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 9B79F12966D for <cfrg@irtf.org>; Wed, 15 Feb 2017 09:05:15 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id u25so157475068qki.2 for <cfrg@irtf.org>; Wed, 15 Feb 2017 09:05:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rPQLotHZVefq48IRqlZOrechzCecrcx+PJ+tH863kbE=; b=oLnwMPD6nMW1EX1vJ19xhi+46DT2g6dYbtn7Psc/wBfeha/b7UV7OkT38b0CXdnj7k OIGW5sFJRFucBPGrBXVOH+bCUK0iCyfWK60PlevhjbeQ8n2uZZp1QEX9F2tkgfbFln6m 6VVSOExDqRbaEEo9EkLDKhTscDmlvQ2CuAGT9e85A5BmY/+9cCLdcV3b3rVpvtMTfTx+ CPzRzncQmsrWd4itMs4RNxIUETIesbPVZU1wE6ZuuPsfbySyCWtuohYFhKtUShQ7Gwax 7/MnxQj4Gr17pJg86CS1HhsP4BDZOoio8V5d8r0OAsWYbmjC6DkS5HOTfJPR+eujDVD5 hIiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rPQLotHZVefq48IRqlZOrechzCecrcx+PJ+tH863kbE=; b=kqgge3qFdAa8yjcygCAR4ZYJd3rLYxsZ+fQgepgiqNWc//VqqEpL72TErcQAr4Tt6m O33mp5LwpkBafMV//wMeR4NcndNjela9r80uo3Ndv0y9qT+8P97Ir30fqo6MZGB2IV1c c0Z3MYcKGpQZY0+UCk/YS8eINFP3bAYn71ceDjmCE8Oo9Y8JICiwbsWGEcPz+1Xxop1B ju+/bLcO+4pt60w5YTtdJCQ+09jnsSLc2j2hBe/BhBnop03KGBPG2IB7IxDs3AAYwxpU yFqN2kjgJ75BWtqVNYSx9bYSNd9b1jQah9Y4ux4J9HK8WUO2JVacmodZZsRXDpEwdXBT 7BzA==
X-Gm-Message-State: AMke39nTNrLvKaKJawbyoDscYLCBH5Rs1+0s72lLkBm3+mfynmNMd83cWJ6GBgL0gIA3BsBryHklRdPH4Utjkw==
X-Received: by 10.233.235.66 with SMTP id b63mr36433927qkg.144.1487178314706; Wed, 15 Feb 2017 09:05:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 09:05:14 -0800 (PST)
In-Reply-To: <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> <CDDC7812-27AF-4566-AE33-6DF829FEB81E@rhul.ac.uk>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 16 Feb 2017 04:05:14 +1100
Message-ID: <CABkgnnX78HnPnudEYOciS-VgJ4opYQX56OQ1R4yYvqxOQkO7Bg@mail.gmail.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/qX5Nzlk6bZzjPwku4JUECbzuCuc>
Cc: 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 17:05:17 -0000

Kenny's response here is quite informative and clarifies this somewhat.

2^24.5 (the current text) is still a big number.  Though it might seem
a little small, I see no practical reason to change it.  In the most
perverse case, that means 520MB of one octet records (23MB of actual
data) before an update is forced.  It's hard to get excited about that
as a practical limitation.

Frankly, I'm more concerned that this isn't small enough and that it
could it be practical to deploy an implementation that don't support
KeyUpdate.  That would cause a real interop problem.

On 16 February 2017 at 00:46, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:
> 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. 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>
> 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
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>