> On 16 Feb 2017, at 14:23, Dang, Quynh (Fed) <quynh.d...@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.pater...@rhul.ac.uk> > Date: Wednesday, February 15, 2017 at 8:46 AM > To: 'Quynh' <quynh.d...@nist.gov> > Cc: Atul Luykx <atul.lu...@esat.kuleuven.be>, Yoav Nir <ynir.i...@gmail.com>, > IRTF CFRG <c...@irtf.org>, "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.d...@nist.gov> wrote: >> >>> Hi Atul, >>> >>> I hope you had a happy Valentine! >>> >>> From: Atul Luykx <atul.lu...@esat.kuleuven.be> >>> Date: Tuesday, February 14, 2017 at 4:52 PM >>> To: Yoav Nir <ynir.i...@gmail.com> >>> Cc: 'Quynh' <quynh.d...@nist.gov>, IRTF CFRG <c...@irtf.org>, >>> "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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
