Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items

[Magnus Westerlund <[e-mail]>]

Den 2016-10-13 kl. 20:12, skrev Cullen Jennings (fluffy):
>
> I think this is huge complexity that is not currently supported and
> not needed. How about we generate the RID such that the RID for the
> n'th m line is n. Or generate it as a random number. Do you see any
> problem with this?
>
> I think this removes all the fingerprinting issues. I'm fine with
> advice that say how to generate the RID in a way that is privacy
> sensitive but I'm not a fan of making RID require support for RTP
> header encryption.
>

So, let disregard the fingerprinting issue for now. It is clear that I 
am in the rough and that this whole issue would benefit from a broad 
review on what we leak when using ICE and RTP/RTCP.

What I don't understand here is that people have argued and agreed that 
we should encrypt the RTP and RTCP packets per default. Then when we 
comes to RTP header extensions we are no longer ready to provide that 
protection per default by ensuring RFC6904 implementation support. So 
RID and MID may not be the most sensitive fields if it has well 
constructed values. Then we have the audio level extensions where Client 
to mixer is RECOMMENDED to be implemented and REQUIRES RFC6904.

So what is the issue, is it that you currently lack RFC6904 
implementations, and thus this require more implementation work, or are 
there additional reasons for wanting to expose this information?

To conclude, I personally think default usage of RFC6904 on header 
extensions would be a good thing. I currently see no reasons for 
changing the requirements that RFC 7941 puts on WebRTC, forcing the 
usage of RFC6904 encryption. If you want to something else, please 
provide a proposal for what that alternative would be.

Cheers

Magnus Westerlund