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

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Randell Jesup
> Sent: Thursday, June 21, 2012 8:02 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] [AVTCORE] Randomly-generated CNAMEs
> 
> 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.

Yeah, that's what I wrote when I became a co-author of
draft-begen-avt-rtp-cnames-02, although was 96 bits (instead of 64),
http://tools.ietf.org/rfcdiff?url2=draft-begen-avt-rtp-cnames-02.txt and
concatenated some other cruft beyond just an RFC4086 random number,

  o  To generate a unique CNAME for each RTP session, an endpoint MAY
      perform SHA1-HMAC [RFC2104] on the concatenated values of the RTP
      endpoint's initial SSRC, the source and destination IP addresses
      and ports, and a randomly-generated value [RFC4086], and then
      truncate the 160-bit output to 96 bits and finally convert the 96
      bits to ASCII using Base64 encoding [RFC4648].  This results in a
      128-bit printable CNAME.  Note that the CNAME MUST NOT change if
      an SSRC collision occurs, hence only the initial SSRC value chosen
      by the endpoint is used.

That text evolved as the document progressed, and veered farther away
from being "just a big random number".  I don't recall why it evolved.

-d

> > 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/
> 
> 
> --
> Randell Jesup
> randell-ietf@jesup.org
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb