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

tim panton <> Wed, 05 March 2014 13:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 153231A00A8 for <>; Wed, 5 Mar 2014 05:59:14 -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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dEjpeqBpA39f for <>; Wed, 5 Mar 2014 05:59:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 71F471A0080 for <>; Wed, 5 Mar 2014 05:59:11 -0800 (PST)
Received: (qmail 39714 invoked from network); 5 Mar 2014 13:59:06 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 8759
Received: from unknown (HELO ( by with SMTP; 5 Mar 2014 13:59:06 -0000
Received: from (localhost []) by (Postfix) with ESMTP id 6920F18A0534; Wed, 5 Mar 2014 13:59:06 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTPSA id 43BDE18A03A0; Wed, 5 Mar 2014 13:59:06 +0000 (GMT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: tim panton <>
In-Reply-To: <>
Date: Wed, 05 Mar 2014 13:59:05 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Cullen Jennings (fluffy)" <>
X-Mailer: Apple Mail (2.1874)
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 13:59:14 -0000

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.