Subject: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 5 Mar 2014 12:32:39 +0000

I am opposed to mandating that Client-to-Mixer Audio Level RTP header is REQUIRED to be encrypted. It means that we can not really build conferencing system where the mixers do not have access to decrypt the media.

I would like to propose that the JS application can control  if the header is encrypted or not.  

I am aware of the paper that suggests these audio levels can reveal the contents of the conversation. There is some element of truth to this. There is also some element of truth to the point that if this was true, speech recognition system would work better than they do. Encrypting this or not is a risk that the application using the header extension needs to evaluate, and WebRTC system needs to provide the applications with a control surfaces that allows them to use this in the way the applications desires.

I will note that an normal application that used this header could decide if it was encrypted or not, what is different in RTCWeb is that we are building a platform and my view is that this platform should allow the applications build on the platform to decide the tradeoffs of risk for encrypting this or not.

---

From: tim panton <[email-masked]>
Date: Wed, 5 Mar 2014 13:59:05 +0000

> I am opposed to mandating that Client-to-Mixer Audio Level RTP header is REQUIRED to be encrypted. It means that we can not really build conferencing system where the mixers do not have access to d…

I have to ask:
Does that matter enough to weaken user security for everyone else? 

> I would like to propose that the JS application can control  if the header is encrypted or not.  

I am deeply uncomfortable about that. I am not a good enough cryptographer to know, but my instinct
is that exposing the fact that (for example) most of the top bits of the ulaw data are zeros in this packet
must be a risk.

I’m pretty confident that one could detect the pitch of the speaker and probably fingerprint that down
to individuals or languages with enough data.

> I am aware of the paper that suggests these audio levels can reveal the contents of the conversation. There is some element of truth to this. There is also some element of truth to the point that i…

I am also uncomfortable about the number of little ad-hoc control surfaces that we seem to be mandating
without an overall design.

My take is that we should push this out to 2.0 when hopefully we will have a designed control surface in place.

> I will note that an normal application that used this header could decide if it was encrypted or not, what is different in RTCWeb is that we are building a platform and my view is that this platfor…

That isn’t the line we have taken in any other encryption discussion.

Tim.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 5 Mar 2014 14:05:53 +0000

Well if people don’t want to allow the application to choose to encrypt this header or not, I will be arguing for MUST NOT encrypt the RTP headers - all of them. 

A recurring theme at IETF is that people trying to protect E2E privacy, do things that result in the real world having the only way they can build applications is to build middle boxes that pretend to to be an end to the things on both sides. This means that the middle boxes end up with 100% ability to change everything and we loose all the protection we hoped to get with E2E security.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 14:25:42 +0000

So there are three things here:
1) MUST the implementation offer encrypted header extensions? (i.e.
mandatory-to-implement)
2) MUST the implementation use encrypted header extensions? (i.e.
mandatory-to-use)
3) MUST the implementation expose an API to control this? (i.e. no SDP
munging needed)

I think we want yes for #1, no for #2, and #3 is potentially interesting
but out of scope for 1.0.
That gives encrypted headers for audio on by default, but remote parties
can negotiate this off using RFC 6904 mechanisms.

On Wed, Mar 5, 2014 at 2:05 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

>
> Well if people don’t want to allow the application to choose to encrypt
> this header or not, I will be arguing for MUST NOT encrypt the RTP headers
> - all of them.
>
> A recurring theme at IETF is that people trying to protect E2E privacy, do
> things that result in the real world having the only way they can build
> applications is to build middle boxes that pretend to to be an end to the
> things on both sides. This means that the middle boxes end up with 100%
> ability to change everything and we loose all the protection we hoped to
> get with E2E security.
>
>
> >> I am opposed to mandating that Client-to-Mixer Audio Level RTP header
> is REQUIRED to be encrypted. It means that we can not really build
> conferencing system where the mixers do not have access to decrypt the
> media.
> >
> > I have to ask:
> >> I am aware of the paper that suggests these audio levels can reveal the
> contents of the conversation. There is some element of truth to this. There
> is also some element of truth to the point that if this was true, speech
> recognition system would work better than they do. Encrypting this or not
> is a risk that the application using the header extension needs to
> evaluate, and WebRTC system needs to provide the applications with a
> control surfaces that allows them to use this in the way the applications
> desires.
> >
> > My take is that we should push this out to 2.0 when hopefully we will
> have a designed control surface in place.
> >
> >>
> >> I will note that an normal application that used this header could
> decide if it was encrypted or not, what is different in RTCWeb is that we
> are building a platform and my view is that this platform should allow the
> applications build on the platform to decide the tradeoffs of risk for
> encrypting this or not.
> >
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: tim panton <[email-masked]>
Date: Wed, 5 Mar 2014 14:28:19 +0000

> A recurring theme at IETF is that people trying to protect E2E privacy, do things that result in the real world having the only way they can build applications is to build middle boxes that pretend…

To me this smacks of special pleading, it would be very useful (for support reasons) if the javascript (optionally)
got access to the names and characteristics of the input devices. We decided as a group that a) the risks of fingerprinting out weighed the benefits b) that we didn’t need a control surface to expose an option for this.

I feel this is an equivalent case, but we seem to be looking at making a different decision.

I’m confident that the desired result could be achieved securely with a combination of webAudio sending appropriate volume data down a data channel set up to the middle box for this purpose.
I realise that would require some extensive rework in the middle box, but thats what happens when you connect a middle box to an ostensibly peer-to-peer system.

Tim.

---

From: tim panton <[email-masked]>
Date: Wed, 5 Mar 2014 14:33:24 +0000

On 5 Mar 2014, at 14:25, Justin Uberti <[email-masked]> wrote:

> 1) MUST the implementation offer encrypted header extensions? (i.e. mandatory-to-implement)
> 2) MUST the implementation use encrypted header extensions? (i.e. mandatory-to-use)
> 3) MUST the implementation expose an API to control this? (i.e. no SDP munging needed)
> 
> I think we want yes for #1, no for #2, and #3 is potentially interesting but out of scope for 1.0.
> That gives encrypted headers for audio on by default, but remote parties can negotiate this off using RFC 6904 mechanisms.
> 

In order to agree with that I’d need to be persuaded that there isn’t a known-plaintext attack risk there
(e.g. detecting a muted mic therefore knowing the ulaw content of a packet), since
any weakening  in DTLS also impacts the data channel and video channels - assuming bundle.

Like I say, I’m not enough of a cryptographer to know.

T.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 5 Mar 2014 14:35:41 +0000

> Like I say, I’m not enough of a cryptographer to know.

No - it does not weaken DTLS to know the plaintext (and if it did, DTLS would have series security problems )

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 14:40:01 +0000

Agree with Cullen (and FWIW the SRTP encryption uses keys vended from the
DTLS master secret, so I think even if you are able to crack the SRTP
crypto it would not be trivial to go backwards up to the DTLS key material)

On Wed, Mar 5, 2014 at 2:35 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> >> That gives encrypted headers for audio on by default, but remote
> parties can negotiate this off using RFC 6904 mechanisms.
> >>
> >

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 5 Mar 2014 14:41:53 +0000

> 1) MUST the implementation offer encrypted header extensions? (i.e. mandatory-to-implement)
I’m fine with yes

> 2) MUST the implementation use encrypted header extensions? (i.e. mandatory-to-use)
I think this needs to be No. Never mind my current use case - if the far end does not negotiate RFC 6094 with the browser, the media and headers should not fail. 

> 3) MUST the implementation expose an API to control this? (i.e. no SDP munging needed)
I prefer control surfaces to SDP munging but as you say, I could live with SDP munging in 1.0 

> That gives encrypted headers for audio on by default, but remote parties can negotiate this off using RFC 6904 mechanisms.

seems workable

---

From: tim panton <[email-masked]>
Date: Wed, 5 Mar 2014 14:52:13 +0000

On 5 Mar 2014, at 14:40, Justin Uberti <[email-masked]> wrote:

> Agree with Cullen (and FWIW the SRTP encryption uses keys vended from the DTLS master secret, so I think even if you are able to crack the SRTP crypto it would not be trivial to go backwards up to the DTLS key material)
> 
> 

Yep, agreed, my mistake.
T.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 14:58:27 +0000

On Wed, Mar 5, 2014 at 2:41 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> I think this needs to be No. Never mind my current use case - if the far
> end does not negotiate RFC 6094 with the browser, the media and headers
> should not fail.
>

Where should this be codified (in which I-D?)

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 05 Mar 2014 16:00:33 +0100

> I am opposed to mandating that Client-to-Mixer Audio Level RTP header is REQUIRED to be encrypted. It means that we can not really build conferencing system where the mixers do not have access to d…
Hi Cullen,

I am not sure I am following you. AFAIK DTLS is only possible to be 
setup between two peers, so in a multiconference solution the mixer will 
anyway have to establish a DTLS/SRTP session which each peer and 
decrypt/encrypt before sending to any of participants in the conference. 
In case of a full meshed conference, there is no need of a mixer at all, 
and the logic could be directly implemented on each of the endpoints.

Am I missing something? Please correct me if I am wrong.

Best regards
Sergio

---

From: tim panton <[email-masked]>
Date: Wed, 5 Mar 2014 15:04:45 +0000

>> That gives encrypted headers for audio on by default, but remote parties can negotiate this off using RFC 6904 mechanisms.

For the record, I still don’t like the idea that the far end can bid-down encryption on this header, but I suppose if my app cares it will have to not offer to do that header extension at all. (Hopefully it is a malleable SDP field).

Tim.

---

From: John Mattsson <[email-masked]>
Date: Wed, 5 Mar 2014 15:21:07 +0000

On 05/03/14 14:05, "Cullen Jennings (fluffy)" <[email-masked]> wrote:

>this header or not, I will be arguing for MUST NOT encrypt the RTP
>headers - all of them.
>
>A recurring theme at IETF is that people trying to protect E2E privacy,
>do things that result in the real world having the only way they can
>build applications is to build middle boxes that pretend to to be an end
>to the things on both sides. This means that the middle boxes end up with
>100% ability to change everything and we loose all the protection we
>hoped to get with E2E security.

Yes, and I think this all-or-nothing problem is going to pop up a lot more
in the future. I think Cullen’s conferencing use case is a good example
where it would have been good to be able to encrypt media client-to-client
but certain rtp headers client-to-mixer (optimally with integrity still
being client-to-client).

John

>>> I am aware of the paper that suggests these audio levels can reveal
>>>the contents of the conversation. There is some element of truth to
>>>this. There is also some element of truth to the point that if this was
>>>true, speech recognition system would work better than they do.
>>>Encrypting this or not is a risk that the application using the header
>>>extension needs to evaluate, and WebRTC system needs to provide the
>>>applications with a control surfaces that allows them to use this in
>>>the way the applications desires.
>> 
>>>decide if it was encrypted or not, what is different in RTCWeb is that
>>>we are building a platform and my view is that this platform should
>>>allow the applications build on the platform to decide the tradeoffs of
>>>risk for encrypting this or not.
>>

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 5 Mar 2014 15:45:54 +0000

On Mar 5, 2014, at 2:25 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

Note that in 6904’s procedures, an offerer has to explicitly offer both encrypted and unencrypted versions of a header extension if it wants to allow the answerer to choose between them.

To support this use case, in RTCWeb terms, this would mean that a browser would a) have to offer both the encrypted and unencrypted versions of the header extension, and b) answer an offer that offered only the unencrypted header by agreeing to use it.

That said, I’m not sure I believe in Cullen’s use case — there’s too much other information that this unauthorized conference mixer wouldn’t be able to do.  (e.g., request I-frames, or detect them, for switching; or generate proper RTCP reports for sometimes-on streams).

On Wed, Mar 5, 2014 at 2:05 PM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 5, 2014, at 1:59 PM, tim panton <[email-masked]<mailto:[email-masked]>> wrote:

>
> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:
>
>>

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 16:09:57 +0000

On 5 March 2014 14:40, Justin Uberti <[email-masked]> wrote:
> DTLS master secret, so I think even if you are able to crack the SRTP crypto
> it would not be trivial to go backwards up to the DTLS key material)

Yes.  DTLS-SRTP extracts keys, so working backwards to the master
secret would mean that not only have you cracked SRTP, but that you
can also produce a HMAC preimage at will.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 16:11:28 +0000

> 3) MUST the implementation expose an API to control this? (i.e. no SDP

I think perhaps we might split this finer and discuss whether the
control is offered for isolated streams or not.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 05 Mar 2014 17:23:07 +0100

El 05/03/2014 16:45, Jonathan Lennox escribió:
>
> That said, I'm not sure I believe in Cullen's use case --- there's too 
> much other information that this unauthorized conference mixer 
> wouldn't be able to do.  (e.g., request I-frames, or detect them, for 
> switching; or generate proper RTCP reports for sometimes-on streams).

I have deeper doubts, I don't really know how a RTP router/mixer would 
be able to work without acting as DTLS endpoint and 
decripting/encripting the RTP data.  Or is there a way to setup/share a 
DTLS session between more than two peers so the same DTLS/SRTP packet is 
decriptable by more than one receiver?

Best regards
Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Mar 2014 17:25:10 +0100

2014-03-05 16:00 GMT+01:00 Sergio Garcia Murillo
<[email-masked]>:
>> I am opposed to mandating that Client-to-Mixer Audio Level RTP header is
>> REQUIRED to be encrypted. It means that we can not really build conferencing
>> system where the mixers do not have access to decrypt the media.
>>
>>
> Hi Cullen,
>
> I am not sure I am following you. AFAIK DTLS is only possible to be setup
> between two peers, so in a multiconference solution the mixer will anyway
> have to establish a DTLS/SRTP session which each peer and decrypt/encrypt
> before sending to any of participants in the conference. In case of a full
> meshed conference, there is no need of a mixer at all, and the logic could
> be directly implemented on each of the endpoints.

Hi Cullen, could you please clarify this? I agree with Sergio: The
mixer (or a media-server before it) has a DTLS and SRTP session with
every participant, so it *already* has to decrypt the received SRTP
(and hence it can decrypt the encrypted RTP header as well) before
processing the media in a mixing fashion (or whichever it does with
it).

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 5 Mar 2014 16:34:32 +0000

EKT is one possible answer to this concern.

By the way: If and when we specify EKT for RTCWEB, there is a simple rule we should establish: A "browser" must not initiate the use of EKT. That way, browser to browser sessions would be unable to force a known key... That could only happen when talking to non-browser endpoints (likely mixers)

Matthew Kaufman

Sent from my iPad

> On Mar 5, 2014, at 8:23 AM, "Sergio Garcia Murillo" <[email-masked]> wrote:
> 
> I have deeper doubts, I don't really know how a RTP router/mixer would be able to work without acting as DTLS endpoint and decripting/encripting the RTP data.  Or is there a way to setup/share a DTLS session between more than two peers so the same DTLS/SRTP packet is decriptable by more than one receiver?
> 
> Best regards
> Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 05 Mar 2014 17:41:00 +0100

In that case, we could link the usage of EKT to unencripted rtp header 
extensions (and not only audio-to-mixer level), moreover as you suggest 
that it would not be enabled in P2P communications and only when a mixer 
is involved.

Best regards
Sergio

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 16:46:49 +0000

> By the way: If and when we specify EKT for RTCWEB, there is a simple rule we should establish: A "browser" must not initiate the use of EKT. That way, browser to browser sessions would be unable to…

I've talked to several people about this and we all agree on this
point.  It's important, if browsers ever implement EKT.

We might also require that "private" sessions not accept attempts to
use EKT too.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Mar 2014 13:22:16 +0000

On Wed, Mar 5, 2014 at 3:45 PM, Jonathan Lennox <[email-masked]> wrote:

>  Note that in 6904’s procedures, an offerer has to explicitly offer both
> encrypted and unencrypted versions of a header extension if it wants to
> allow the answerer to choose between them.
>
>  To support this use case, in RTCWeb terms, this would mean that a
> browser would a) have to offer both the encrypted and unencrypted versions
> of the header extension, and b) answer an offer that offered only the
> unencrypted header by agreeing to use it.
>

That is a good point, and implies that for any header extension that
recommends encryption (e.g. RFC 6464 for audio level), we have the
following choices:
a) Implementations MUST offer only the encrypted version, and MUST accept
only the encrypted version
b) Implementations MUST offer both the encrypted and unencrypted versions,
and MUST accept both

Of these, a) is the less complicated option.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 13:49:30 +0000

> b) Implementations MUST offer both the encrypted and unencrypted versions,

"either"?

> Of these, a) is the less complicated option.

I agree.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Mar 2014 13:52:28 +0000

> > b) Implementations MUST offer both the encrypted and unencrypted

Right, that is what I meant.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Mar 2014 13:54:22 +0000

On Mar 6, 2014, at 1:22 PM, Justin Uberti <[email-masked]> wrote:

> That is a good point, and implies that for any header extension that recommends encryption (e.g. RFC 6464 for audio level), we have the following choices:
> a) Implementations MUST offer only the encrypted version, and MUST accept only the encrypted version
> b) Implementations MUST offer both the encrypted and unencrypted versions, and MUST accept both
> 

To be precise, 6904 says an answerer MUST NOT accept both encrypted and unencrypted versions of the same header (in the same answer).  I think option b) should say that Implementations MUST be prepared to accept either encrypted and unencrypted.  [I.e., I agree with Martin, whose e-mail came in while I was writing this.]

If we go this way, there’s then a W3C question of whether to provide an API knob to choose between the encrypted and unencrypted version of the header extension.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 13:55:48 +0000

> If we go this way, there’s then a W3C question of whether to provide an API knob to choose between the encrypted and unencrypted version of the header extension.

That's a very good reason to go with option a :)  I don't want to
expose that knob to the Internet.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Mar 2014 13:57:05 +0000

Hi,

I am not okay with changing 1). I think we MUST mandate implementation
of Header Extension encryption if you implement the audio level header
extensions.

When it comes to use level I am fine with reducing this to RECOMMENDED,
with a reasonable motivation, like enabling middleboxes that can avoid
to be in the security context to read these headers. Thus resulting in a
trade-off between what information one leaks, versus the impact of
having the middlebox in the security context. It may also need to be
made clear that the trade-off for this may further be changed as we
learn more about the feasibility of performing the attack of learning
the content of the voice communication based on the audio levels.

I realize that the above is mostly useful if one actually gets a control
knob for this. But, that is a question for the API.

>From my perspective, allowing for exceptions to the default encryption
on, when so indicated, is the best way forward.

Cheers

Magnus

On 2014-03-05 14:25, Justin Uberti wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Well if people don’t want to allow the application to choose to
>     encrypt this header or not, I will be arguing for MUST NOT encrypt
>     the RTP headers - all of them.
> 
>     A recurring theme at IETF is that people trying to protect E2E
>     privacy, do things that result in the real world having the only way
>     they can build applications is to build middle boxes that pretend to
>     to be an end to the things on both sides. This means that the middle
>     boxes end up with 100% ability to change everything and we loose all
>     the protection we hoped to get with E2E security.
> 
> 
>     > On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >>
>     >> I am opposed to mandating that Client-to-Mixer Audio Level RTP
>     header is REQUIRED to be encrypted. It means that we can not really
>     build conferencing system where the mixers do not have access to
>     decrypt the media.
>     >
>     > I have to ask:
>     > is that exposing the fact that (for example) most of the top bits
>     of the ulaw data are zeros in this packet
>     > must be a risk.
>     >
>     > I’m pretty confident that one could detect the pitch of the
>     speaker and probably fingerprint that down
>     >> I am aware of the paper that suggests these audio levels can
>     reveal the contents of the conversation. There is some element of
>     truth to this. There is also some element of truth to the point that
>     if this was true, speech recognition system would work better than
>     they do. Encrypting this or not is a risk that the application using
>     the header extension needs to evaluate, and WebRTC system needs to
>     provide the applications with a control surfaces that allows them to
>     use this in the way the applications desires.
>     >
>     > My take is that we should push this out to 2.0 when hopefully we
>     will have a designed control surface in place.
>     >
>     >>
>     >> I will note that an normal application that used this header
>     could decide if it was encrypted or not, what is different in RTCWeb
>     is that we are building a platform and my view is that this platform
>     should allow the applications build on the platform to decide the
>     tradeoffs of risk for encrypting this or not.
>     >
>     [email-masked] <mailto:[email-masked]>

-- 

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 (fluffy)" <[email-masked]>
Date: Thu, 6 Mar 2014 14:36:10 +0000

> on, when so indicated, is the best way forward.

I agree with Magnus - must implement is fine with me, but because using this feature can have really bad privacy implications, I don’t want this as MUST use. I want the application to be able choose if it uses the feature or not. And of course, the spec needs to have sufficient guidance on the risks.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 6 Mar 2014 14:45:44 +0000

> That said, I’m not sure I believe in Cullen’s use case — there’s too much other information that this unauthorized conference mixer wouldn’t be able to do.  (e.g., request I-frames, or detect them,…

I talked to Jonathan about this offline and I think there are solutions to these issue using EKT but it really needs a draft to explain the overall system. I will probably do that before Toronto.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Mar 2014 21:47:28 -0700

Cullen said:

"I am opposed to mandating that Client-to-Mixer Audio Level RTP header is
REQUIRED to be encrypted. It means that we can not really build
conferencing system where the mixers do not have access to decrypt the
media."

[BA] I am also not enthused about mandating encryption of header
extensions. However, in the interest of fairness, it is worth pointing out
that header extensions are optional, so if a particular extension is
encrypted, the mixer can always ignore it (and in this case, thereby do
more work mixing muted audio streams).  So my take would be to say SHOULD
encrypt Client-to-MIxer Audio level, but leave this up to negotiation so
that if the mixer doesn't want it encrypted, it can turn that off.

On Wed, Mar 5, 2014 at 4:32 AM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> REQUIRED to be encrypted. It means that we can not really build
> I will note that an normal application that used this header could decide
> if it was encrypted or not, what is different in RTCWeb is that we are
> building a platform and my view is that this platform should allow the

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Mar 2014 21:21:24 -0700

I agree we need to mandate implementation of encryption for the c2m audio
level headers. For actual use, what controls do we want - the ability to
offer one of (encrypted, encrypted + unencrypted, none)?

On Mon, Mar 10, 2014 at 9:47 PM, Bernard Aboba <[email-masked]>wrote:

> On Wed, Mar 5, 2014 at 4:32 AM, Cullen Jennings (fluffy) <[email-masked]
> > wrote:
>
>>