Re: [AVTCORE] Randomly-generated CNAMEs

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/