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

[John Mattsson <[e-mail]>]

On 05/03/14 14:05, "Cullen Jennings (fluffy)" <[e-mail]> 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.

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

> 
>
>
>On Mar 5, 2014, at 1:59 PM, tim panton <[e-mail]> wrote:
>
>> 
>> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) <[e-mail]>
>>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:
>> 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 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 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 platform should
>>>allow the applications build on the platform to decide the tradeoffs of
>>>risk for encrypting this or not.
>> 
>> That isn’t the line we have taken in any other encryption discussion.
>> 
>> Tim.
>> 
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb