Hi On 13/07/2016 11:55, "Dang, Quynh (Fed)" <[email protected]> wrote:
>Good morning Kenny, > >On 7/12/16, 3:03 PM, "Paterson, Kenny" <[email protected]> wrote: > >>Hi, <snip> >>Could you define "safe", please? Safe for what? For whom? >> >>Again, why are you choosing 2^-32 for your security bound? Why not 2^-40 >>or even 2^-24? What's your rationale? Is it just finger in the air, or do >>you have a threat analysis, or ...? > >I said it is safe because the chance of 1 in 4,294,967,296 practically >does not happen. I am not interested in talking about other numbers and >other questions. OK, then I think we're done here. >>> I don¹t >>> recommend to run another function/protocol when there are no needs for >>>it. >>> I don¹t see any particular reasons for mentioning single key in the >>> indistinguishability attack here. >>> >> >>Then please read a little further into the note that presents the >>analysis: a conservative but generic approach dictates that, when the >>attacker has multiple keys to attack, we should multiply the security >>bounds by the number of target keys. >> >>A better analysis for AES-GCM may eventually be forthcoming but we don't >>have it yet. >> >>>> Then do you have a >>>> specific concern about the security of rekeying? I could see various >>>>ways >>>> in which it might go wrong if not designed carefully. >>>> >>>> Or are you directly linking a fundamental security question to an >>>> operational one, by which I mean: are you saying we should trade >>>>security >>>> for avoiding the "cost" of rekeying for some notion of "cost"? If so, >>>>can >>>> you quantify the cost for the use cases that matter to you? >> >>I'd love to have your answer to these questions. I didn't see one yet. >>What is the cost metric you're using and how does it quantity for your >>use cases? > >Again, I am not interested in other questions. I suggested the number >about 2^38 records because it is a safe data bound because Eric put in his >tls 1.3 draft the number 2^24.5 which is unnecessarily small. Again, look like we're done here. >Your paper is a nice one which gives users good information about choices. Thanks, I'm glad you found it useful. Cheers Kenny > >> >>Cheers, >> >>Kenny >> >>>> >>>> Cheers, >>>> >>>> Kenny >>> >>> Regards, >>> Quynh. > >Regards, >Quynh. >>> >>> >>> >>> > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
