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

["Cullen Jennings (fluffy)" <[e-mail]>]

> On Oct 14, 2016, at 2:26 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> 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.

That broad review was largely done as part of PERC. 

> 
> 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 the audio levels are recommended in WebRTC but this MID stuff is a very generic mechanism that will like be broadly used to deal with RTP lack of extensibility of size PT space. Lot of stuff does not implement audio levels and some stuff that implements it does not encrypt it. The 6904 mechanism is not exactly elegant, not easy to implement, and doubles the size the headers which is not great for audio. I think it is fair to say we might do it differently if doing it over again. 

> 
> 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?

Yes this adds needless security complexity that people don't see the value in thus it becomes difficult to convince implementors to do it.

> 
> 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.

Originally MID was not a SDES items, I'd propose just moving it back to a normal RTP Header. In looking at trying to use this in deployments, it's hard to see what value transporting it in RTCP as well as RTP provided.  When that was originally proposed, I don't think anyone realized that mean encrypting it and did not really care if it was normal or SDES as it was about the same work. But if SDES means it needs to be encrypted, then I think we need to reconsider that. 


> 
> Cheers
> 
> Magnus Westerlund
>