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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Oct 2016 15:55:07 +0200

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: [email-masked]
----------------------------------------------------------------------

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Oct 2016 10:41:53 -0700

How are these a significant fingerprinting problem ?

> On Oct 6, 2016, at 7:55 AM, Magnus Westerlund <[email-masked]> 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
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Oct 2016 20:32:50 -0700

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 <[email-masked]> wrote:
> 
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Sat, 8 Oct 2016 14:44:25 +0000

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 <[email-masked]> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Oct 2016 10:24:21 +0000

Hi,

On the MMUSIC list Jonathan L informed the community about the following text in RFC 7904 (SDES header extensions):

   "In RTP sessions where any type of confidentiality protection is
   enabled for RTCP, the SDES item header extensions MUST also be
   protected."

So, *IF* we assume that "any type of confidentiality protection" is enabled for RTCP, I guess the answer is pretty clear, or?

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: 08 October 2016 17:44
To: Bernard Aboba <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items

Mo

>> ---------------------------------------------------------------------
>> - Services, Media and Network features, Ericsson Research EAB/TXM

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Oct 2016 11:05:21 +0200

> So, *IF* we assume that "any type of confidentiality protection" is enabled for RTCP, I guess the answer is pretty clear, or?

Yes, from my perspective this is settled. RFC 7904 forces encryption of 
the MID value in an WebRTC context. If the RTCWeb WG do not agree with 
this, then it needs to work on changing RFC 7904. I do not support 
chaning that RFC's conclusion that information that is protected in RTCP 
needs to be protected also in RTP headers.

When it comes to the information leakage and the fingerprinting 
possibilities of SSRCs, PTs etc, it is present and getting worse in 
multi-stream systems.

So when you had a single media stream per endpoint and that used a 
random SSRC and one PT value during the life-time of the RTP session, 
there is very little information leakage here. The codec possibly leaks 
through PT, but the packet length, at least for audio leaks that 
information anyway.

However, when one starts to have a endpoint that uses multiple media 
streams, and certain configurations of RTX and FEC, then the publicly 
visable fingerprinting surface from RTP streams goes up. Now both 
implementation choices as well as device hardware configurations starts 
to show in the unencrypted RTP headers. So MID and RID is one additional 
parameter that increases the potential for fingerprinting here.

So what is the reason given that we protect the RTP payload and the RTCP 
packets with encryption, to not also protected the RTP header extensions?

Cheers

Magnus Westerlund

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 13 Oct 2016 18:12:28 +0000

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.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Oct 2016 12:20:21 -0600

> On Oct 10, 2016, at 3:05 AM, Magnus Westerlund <[email-masked]> wrote:
> 

Just one note - I think you mean RFC 7941 here.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Oct 2016 19:05:18 +0000

>> On the MMUSIC list Jonathan L informed the community about the following text in >> RFC 7904 (SDES header extensions):
>> 

Correct :)

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Oct 2016 10:26:12 +0200

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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 14 Oct 2016 13:08:05 +0000

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

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 14 Oct 2016 15:02:56 +0000

On Oct 14, 2016, at 9:08 AM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:

Not elegant is a matter of taste, but I have to disagree with your other two claims about 6904.

It doesn’t expand the size of the RTP header extensions at all, over what standard 5285 header extensions do. (Now, 5285 itself is fairly space-wasteful, but that’s a separate issue.)

And I don’t think it was very hard to implement, either — the patch to add it to libsrtp is only 800 lines of code (https://github.com/cisco/libsrtp/commit/ce37ef61444400370f699c44985949ba44557d00), more than half of which is test cases.

Are you actually criticizing the 5285 mechanism itself?

—
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Oct 2016 10:46:36 +0200

Den 2016-10-14 kl. 15:08, 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.
>

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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2016 13:28:50 +0000

Hi,

draft-ietf-avtext-rid also talks about encryption, and references RFC
7201. Any input from the authors of that document? Adam? Suhas? Peter?

Regards,

Christer

On 17/10/16 11:46, "rtcweb on behalf of Magnus Westerlund"
<[email-masked] on behalf of [email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2016 19:56:51 +0000

Hi,

I'd like some guidance on how to move forward and try to solve this issue. I really don't want us to switch to another mechanism at this point.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: 17 October 2016 11:47
To: Cullen Jennings (fluffy) <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items

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

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.

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

>> are there additional reasons for wanting to expose this information?
>
> value in thus it becomes difficult to convince implementors to do it.
>
>>

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.

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