Re: [rtcweb] [AVTCORE] Randomly-generated CNAMEs

[Randell Jesup <[e-mail]>]

On 6/21/2012 7:12 PM, Eric Rescorla wrote:
> This matches my analysis.

Mine also, and I agree a 64-bit cryptographically random number is safer 
against collision than the RFC 6222 value, unless you *want* to be able 
to reverse the operation to find the inputs.  I agree with Justin that 
there's no reason we can see to implement RFC6222 instead of using a 
64-bit random number per above, and plenty of reasons to use the 64-bit 
number.

> On Thu, Jun 21, 2012 at 4:09 PM, Kevin Gross <[e-mail]> wrote:
>> It seems like, pure random CNAMEs would have the same or better probability
>> of uniqueness compared to the hashed values specified in 6222. I don't think
>> it is difficult to prove this if you assume the hash function does what it's
>> designed to and makes data white. 48 is not enough bits to ensure uniqueness
>> of a large population of random numbers. If I remember correctly, 64 bits is
>> where the statistics start to get comfortable. See
>> http://en.wikipedia.org/wiki/Birthday_problem. Potentially there's a bigger
>> problem here than linkability :(
>>
>> Kevin Gross
>>
>> On Thu, Jun 21, 2012 at 4:28 PM, Colin Perkins <[e-mail]> wrote:
>>>
>>> On 21 Jun 2012, at 23:10, Eric Rescorla wrote:
>>>> On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins <[e-mail]>
>>>> wrote:
>>>>> On 21 Jun 2012, at 20:09, Martin Thomson wrote:
>>>>>> On 21 June 2012 05:48, Eric Rescorla <[e-mail]> wrote:
>>>>>>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings <[e-mail]>
>>>>>>> wrote:
>>>>>>>> I think what EKR was getting at is that if A call B in one phone
>>>>>>>> call, then day later A wants to make an anonymous call to B, B should not be
>>>>>>>> able to tell the second call is coming from same devices. I think that was
>>>>>>>> part of the goal of 6222 but from EKR's email it looks like it fails to
>>>>>>>> provide that.
>>>>>>>
>>>>>>> Exactly.
>>>>>>
>>>>>> I agree with the analysis.  The idea that the same browser could be
>>>>>> correlated across two independent sessions bothers me.  Within the one
>>>>>> "session", fine - on the contrary, mandatory.  Outside of that, I'd
>>>>>> like at least an option for anonymity.
>>>>>
>>>>> Using SRTP to encrypt the traffic will stop third-parties correlating
>>>>> the sessions, and RTCWeb is mandates SRTP and encryption.
>>>>
>>>> I'm concerned about tracking by people who are second parties.
>>>>
>>>> Consider the case where I call you from an anonymous phone at a domestic
>>>> violence shelter. I record the CNAME and then call all the DV shelters until
>>>> I determine which one has a CNAME from the same device.
>>>>
>>>>> RFC 6222 does define per-session RTCP CNAME values, if you're concerned
>>>>> about the called party being able to correlate sessions based on the RTCP
>>>>> CNAME. We could mandate those instead of short-term persistent RTCP CNAME
>>>>> values. If that's not sufficient, then someone will need to write a draft
>>>>> that defines a new RTCP CNAME generation algorithm, which this draft can
>>>>> refer to.
>>>>
>>>> The problem is that those per-session CNAME values do not appear to be
>>>> unlinkable. I.e., they are distinct but they are generated from the same
>>>> underlying data with insufficient entropy to prevent someone who knows two
>>>> CNAMEs from determining if they are from the same device.
>>>>
>>>> As far as new algorithm goes, is there some reason "Random" isn't good
>>>> enoguh?
>>>
>>>
>>> There's some discussion in RFC 3550 Section 6.5.1 and RFC 6222. It might
>>> be possible to use a random choice, provided the same random value is used
>>> across all sessions that need to be correlated, and the value is chosen to
>>> be unique with high probability. I haven't thought about it in detail. In
>>> any case, it's an update to RFC 3550 and RFC 6222, so someone will have to
>>> write up the draft defining this.
>>>
>>> --
>>> Colin Perkins
>>> http://csperkins.org/


-- 
Randell Jesup
[e-mail]