Re: [AVTCORE] Randomly-generated CNAMEs

One again, I think we have complete failure on the meaning of the word session :-) 

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. 

On Jun 21, 2012, at 6:22 , Colin Perkins wrote:

> Ekr,
> 
> I'm not sure I understand what problem you're trying to solve: the point of the CNAME is to allow different RTP sessions to be linked. 
> 
> Colin
> 
> 
> On 21 Jun 2012, at 03:04, Eric Rescorla wrote:
>> RFC 6222 specifies two CNAME generation algorithms:
>> 
>> - Persistent CNAMEs based on UUIDs
>> - Short-term CNAMEs based on a digest of the MAC address and time of day.
>> 
>> However, reading this document and the security considerations it seems like both methods produce CNAMEs which aren't unlinkable. Obviously the persistent CNAMEs are linkable, and it doesn't look like short-term CNAMEs have enough entropy to be unlinkable either. Specifically, the inputs are (Section 5):
>> 
>> 1. The MAC address (or EUI-64)
>> 2. The time of day (NTP-style)
>> 3. Initial SSRC, and IP/port quartet
>> 
>> (3) is known to the other side, (2) is at most 48-bits (and practically much less) and (2) is known to within a fairly narrow margin (and, it appears, communicated in the RTP timestamp).
>> 
>> The upshot is that it seems likely that I can link two RTP sessions from the same person. Note that RFC 6222 doesn't say otherwise. Rather, it says:
>> 
>> This document uses a hash function to ensure the uniqueness of RTCP
>>  CNAMEs.  A cryptographic hash function is used because such functions
>>  provide the randomness properties that are needed.  However, no
>>  security assumptions are made on the hash function.  The hash
>>  function is not assumed to be collision resistant, preimage
>>  resistant, or second preimage resistant in an adversarial setting; as
>>  described above, an attacker attempting an impersonation attack could
>>  merely set the RTCP CNAME directly rather than attacking the hash
>>  function.  Similarly, the hash function is not assumed to be a one-
>>  way function or pseudorandom in a cryptographic sense.
>> 
>> For privacy reasons, it would be nice to be able to generate CNAMEs randomly so that they're not linkable. Unfortunately, 6222 seems to require that short-term credentials be generated via the above mechanism. Is there any reason why that shouldn't be allowed?
>> 
>> -Ekr
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt