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

Jonathan Lennox <> Wed, 05 March 2014 15:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A2E021A0739 for <>; Wed, 5 Mar 2014 07:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G9j42UDHN5kS for <>; Wed, 5 Mar 2014 07:46:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CDFB71A00DA for <>; Wed, 5 Mar 2014 07:45:59 -0800 (PST)
X-Note-AR-ScanTimeLocal: 3/5/2014 10:45:55 AM
X-Policy: GLOBAL -
X-Policy: GLOBAL -
X-Policy: GLOBAL -
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-500/SG:5 3/5/2014 10:45:07 AM
X-GBUdb-Analysis: 0,, Ugly c=0.862181 p=-0.98233 Source White
X-Signature-Violations: 0-0-0-21141-c
X-Note-419: 31.2006 ms. Fail:0 Chk:1345 of 1345 total
X-Note: SCH-CT/SI:0-1345/SG:1 3/5/2014 10:45:41 AM
X-Note: Spam Tests Failed:
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [] (HELO by (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 77492778; Wed, 05 Mar 2014 10:45:54 -0500
Received: from ([fe80::50:56ff:fe85:6b62]) by ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 5 Mar 2014 09:45:54 -0600
From: Jonathan Lennox <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level
Thread-Index: AQHPOIXa97MYXf3mNUS0a1X98yqSFprTB4SA
Date: Wed, 05 Mar 2014 15:45:54 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E7C174FBB1374E6D81AC06C8C2B30FE1vidyocom_"
MIME-Version: 1.0
Cc: Cullen Jennings <>, "" <>
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:46:03 -0000

On Mar 5, 2014, at 2:25 PM, Justin Uberti <<>> wrote:

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.

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) <<>> 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 Mar 5, 2014, at 1:59 PM, tim panton <<>> wrote:

> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) <<>> 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<>

rtcweb mailing list<>