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

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 <bernard.aboba@gmail.com>wrote:

> 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) <fluffy@cisco.com
> > 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 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.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>