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

This matches my analysis.

-Ekr

On Thu, Jun 21, 2012 at 4:09 PM, Kevin Gross <kevin.gross@avanw.com> 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 <csp@csperkins.org> wrote:
>>
>> On 21 Jun 2012, at 23:10, Eric Rescorla wrote:
>> > On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins <csp@csperkins.org>
>> > wrote:
>> >> On 21 Jun 2012, at 20:09, Martin Thomson wrote:
>> >>> On 21 June 2012 05:48, Eric Rescorla <ekr@rtfm.com> wrote:
>> >>>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings <fluffy@iii.ca>
>> >>>> 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/
>>
>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>
>