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

[Magnus Westerlund <[e-mail]>]

Den 2016-10-14 kl. 15:08, skrev Cullen Jennings (fluffy):
>
>> 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.
>

I do not agree that review happened in that context. I can't remember 
that we discussed fingerprinting at all. We quickly put any effort of 
privacy in regards to that the communication occurs out of scope. All 
the focus in PERC is to my understanding on maintaining confidentiality 
of the media content as well as preventing third party injection, 
modifications (other than sub selection of content)  and replay attacks.



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

I think Jonathan had an excellent reply on this.

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

So, I think moving away from SDES item is a bad idea. As that would 
create additional implementation burden, rather than having the same 
processing for a number of SDES items of similar type. RID, MID and 
CNAME all need similar processing for initial startup handling. So 
moving RID out, while still having the other two just creates an 
additional cases to implement.

When it comes to RTCP inclusion of these SDES items I know of two reasons.

Reason one, is that one can actually use RTCP to send these for an SSRC 
prior to having RTP data to send for it. That enables one to have the 
association in place prior to actually having to handle media data.

Reason two is the saftey net RTCP provides. It enables a receiver to 
detect if its state is out of sync. Yes, this could be realized using 
periodic repeats in the RTP header extension also. However, that doesn't 
work if the SSRC currently don't have any data to send.

Considering the state that draft-ietf-avtext-rid is in. Deciding to 
change it to not be an SDES item is going be an equal if not greater 
hassle to actually pull it back to the WG to include a beef up of the 
security consdieration with an motivation why the rules in RFC7941 do 
not apply to it. Assuming that is what the consensus ends up being.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------