Hi,
> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) <quynh.d...@nist.gov> wrote:
>
> Hi Kenny,
>
>> On 7/12/16, 1:39 PM, "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> wrote:
>>
>> Hi
>>
>>> On 12/07/2016 18:12, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:
>>>
>>> Hi Kenny,
>>>
>>>> On 7/12/16, 1:05 PM, "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> wrote:
>>>>
>>>> Hi
>>>>
>>>>> On 12/07/2016 16:12, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:
>>>>>
>>>>> Hi Kenny,
>>>>>
>>>>> I support the strongest indistinguishability notion mentioned in (*)
>>>>> above, but in my opinion we should provide good description to the
>>>>> users.
>>>>
>>>> OK, I think now we are at the heart of your argument. You support our
>>>> choice of security definition and method of analysis after all.
>>>>
>>>> And we can agree that good descriptions can only help.
>>>>
>>>>> That is why I support the limit around 2^38 records.
>>>>
>>>> I don't see how changing 2^24.5 (which is in the current draft) to 2^38
>>>> provides a better description to users.
>>>>
>>>> Are you worried they won't know what a decimal in the exponent means?
>>>>
>>>> Or, more seriously, are you saying that 2^{-32} for single key attacks
>>>> is
>>>> a big enough security margin? If so, can you say what that's based on?
>>>
>>> It would not make sense to ask people to rekey unnecessarily. 1 in 2^32
>>> is
>>> 1 in 4,294,967,296 for the indistinguishability attack.
>>
>> I would agree that it does not make sense to ask TLS peers to rekey
>> unnecessarily. I also agree that 1 in 2^32 is
>> 1 in 4,294,967,296. Sure looks like a big, scary number, don't it?
>>
>> Are you then arguing that 2^{-32} for single key attacks is a big enough
>> security margin because we want to avoid rekeying?
>
> Because it is safe therefore there are no needs to rekey.
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 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?
Cheers,
Kenny
>>
>> Cheers,
>>
>> Kenny
>
> Regards,
> Quynh.
>
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
