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

Many implementors just assume "0" for any random number they need to come up with. So, saying to choose a random number may not cut it.

-acbegen

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin Gross
> Sent: Thursday, June 21, 2012 7:09 PM
> To: Colin Perkins
> Cc: Martin Thomson; rtcweb@ietf.org; avt@ietf.org; Cullen Jennings
> Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs
> 
> 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
> 
> 