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

MID and RID are similar to PT in this regard. They are all arbitrary values that only have semantic meaning when combined with a media description in external signaling. Any genuine concern over privacy or fingerprinting issues with MID and RID should first consider PT. I'm unaware of any concerns expressed over unencrypted PT.

Note that it is possible to use encrypted SRTCP to convey MID and RID without including them in SRTP packets. One proposed version of the RTP demux rules has explicitly noted this approach of using RTCP to latch MID/RID to an SSRC even if RTP does not contain those header extensions for that SSRC. 

Mandating encrypted SRTCP seems more palatable than mandating encrypted RTP header extensions. But I don't think a good case has been made yet for either, especially considering PT is always unencrypted. 

Mo

On Oct 7, 2016, at 11:33 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

I don't see how snooping the MID and RID would provide info that could not be obtained in other ways. For example, an observer can tell audio from video traffic just by looking at packet sizes. Similarly, simulcast streams will originate from different SSRCs so no need to snoop the RID to figure out that there are multiple streams being sent (or even which ones are related since traffic will be correlated).

> On Oct 7, 2016, at 10:41, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> 
> How are these a significant fingerprinting problem ?
> 
> 
>> On Oct 6, 2016, at 7:55 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>> 
>> WG,
>> 
>> After discussion in AVTEXT and MMUSIC regarding the inclusion of MID and RID as SDES items that this do exposes labels that previously only have existed in the signalling plane in the media plane. And especially in the RTP header extensions, where even if the media payload is encrypted the header extension is not encrypted.
>> 
>> The risk with this is primarily a privacy and fingerprinting risk. And the proposed mitgation is encryption of the RTP header extensions in both the bundle and avtext-rid documents.
>> 
>> This leads to the conclusion that for RTCWeb, we must consider to act on these recommendations and decide on which implementation and usage requirement the protection of these field should have.
>> 
>> My proposal is that implementation and use of RFC6904 encryption of the RTP header extensions are REQUIRED. For RTCP it is actually unclear if there is mandatory to use encrypted SRTCP. I think it should be required and that can be clarified in Section 5.5 of draft-ietf-rtcweb-security-arch.
>> 
>> 
>> Opinions?
>> 
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Färögatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb