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

John Mattsson <> Wed, 05 March 2014 15:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3B691A0270 for <>; Wed, 5 Mar 2014 07:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0NJlF4CN9OhD for <>; Wed, 5 Mar 2014 07:21:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 08A981A014F for <>; Wed, 5 Mar 2014 07:21:13 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-8a-531740e58efc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F7.58.23809.5E047135; Wed, 5 Mar 2014 16:21:09 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 16:21:08 +0100
From: John Mattsson <>
To: "Cullen Jennings (fluffy)" <>, tim panton <>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level
Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8SfprSdIKAgAAB5oCAABTlAA==
Date: Wed, 05 Mar 2014 15:21:07 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje5TB/Fgg+8vTSw6JrNZrP3Xzm5x cfstRgdmjym/N7J6LFnyk8ljyaRGtgDmKC6blNSczLLUIn27BK6M7Zu3Mhb8UqnYsCKkgbFB pYuRk0NCwERi77+TTBC2mMSFe+vZQGwhgUOMErdX5HQxcgHZixkl5i9cCVbEJmAgMXdPA1iR iEC4xMd9f5lBbGYBdYk7i8+xg9jCAkESU9omAMU5gGqCJdqaRCDKnSSW729jBLFZBFQkVj56 BVbOK2AmcWbNIRaIvasYJSZvNASxOQVsJW7P7gQbzwh02/dTa5ggVolL3HoyH+pmAYkle84z Q9iiEi8f/2MFsUUF9CTuPZrLAhFXklh7eDsLyDnMApoS63fpQ4yxlpi+/BoLhK0oMaX7IdQ5 ghInZz5hmcAoMQvJtlkI3bOQdM9C0j0LSfcCRtZVjOy5iZk56eVGmxiBUXdwy2/VHYx3zokc YpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OM0gpzZungeb1O05fs3zbJ 6TrbFYEv73iPmiYfuFSdOXF60MaNt5d3Ovk2XyyTW//im3PnzhObw5W/2vkeirJdbx20/+Ry I8t9Gf5zbrcnCMSyB09UdXfJr9RfvfYzp3/cwc7PaWu4U4xbbz80/nTE9bwF64tFJr7PzXWr Tp/REv9avXHvsZ1KLMUZiYZazEXFiQDxwVoGiAIAAA==
Cc: "" <>
Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Mar 2014 15:21:17 -0000

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


>On Mar 5, 2014, at 1:59 PM, tim panton <> wrote:
>> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) <>
>>> 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
>> 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