[rtcweb] Text proposal for change regarding Audio level security in draft-ietf-rtcweb-rtp-usage

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 04 April 2014 09:31 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94561A0127 for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 02:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E0mggdmH65F for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 02:31:17 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 173B41A001D for <rtcweb@ietf.org>; Fri, 4 Apr 2014 02:31:16 -0700 (PDT)
X-AuditID: c1b4fb38-b7f518e000000889-f9-533e7bdf970d
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A1.50.02185.FDB7E335; Fri, 4 Apr 2014 11:31:11 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.174.1; Fri, 4 Apr 2014 11:31:11 +0200
Message-ID: <533E7BDF.8030903@ericsson.com>
Date: Fri, 04 Apr 2014 11:31:11 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvje79artgg4eXdCyWvzzBaLH2Xzu7 A5PHtPv32TyWLPnJFMAUxWWTkpqTWZZapG+XwJXx69dBxoIfshU37z1jbGB8L97FyMkhIWAi cWLqBzYIW0ziwr31QDYXh5DAUUaJS7O7WCGcZYwSL37PYQKp4hXQlji+bTsziM0ioCLxYc86 sG42AQuJmz8awWxRgWCJpXMWs0DUC0qcnPkEzBYRUJe4/PACO4jNLKAqcX7feVYQW1ggXmLP 5xtANRxAV4hL9DQGQZToSUy52sIIYctLNG+dDbZWCOiEhqYO1gmMArOQbJiFpGUWkpYFjMyr GDmKU4uTctONDDYxAoPv4JbfFjsYL/+1OcQozcGiJM778a1zkJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGG5lJxa8WR2zYV1XweFn4YUth37Ur75ifaYuMclAsSXs/2fn/9G/fch5P3rx9 0cy3/Wk5XdEeeeaTM6uKupk+6KbxBGdmXb2ypUd9eYrxdZkstt3hMcZHPy45/z3ytNfLUzdX ZMxNMjS5a3kw+/QM07OJYZaJWw+1yczZUHr3yIrSgEur7WKYlFiKMxINtZiLihMBQxm9SwwC AAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l20gSkm75SV67qoE_XlEJ3mtQlk
Cc: Colin Perkins <csp@csperkins.org>
Subject: [rtcweb] Text proposal for change regarding Audio level security in draft-ietf-rtcweb-rtp-usage
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 09:31:22 -0000

WG,
(As Author)

There was some discussion at the meeting and afterwards regarding the
encryption of the audio level header extensions. This made us authors
review the text on this. We have clarified the text to require
implementation of header extension encryption and recommend usage,
unless explicitly requested to turn it off. See text below from Section
5.2.2., 5.2.3 and Section 13. We appreciate feedback on this change. We
plan to include this in the next draft update.


5.2.2.  Client-to-Mixer Audio Level

   The Client to Mixer Audio Level extension [RFC6464] is an RTP header
   extension used by a client to inform a mixer about the level of audio
   activity in the packet to which the header is attached.  This enables
   an RTP middlebox to make mixing or selection decisions without
   decoding or detailed inspection of the payload, reducing the
   complexity in some types of mixer.  It can also save decoding
   resources in receivers, which can choose to decode only the most
   relevant RTP packet streams based on audio activity levels.

   The Client-to-Mixer Audio Level [RFC6464] extension is RECOMMENDED to
   be implemented.  If the header extension is implemented, it is
   REQUIRED that implementations is capable of encrypting the header
   extension according to [RFC6904] since the information contained in
   these header extensions can be considered sensitive.  It is further
   RECOMMENDED that this encryption is used, unless the encryption has
   been explicitly requested to be turned off through API or signalling.

5.2.3.  Mixer-to-Client Audio Level

   The Mixer to Client Audio Level header extension [RFC6465] provides
   the client with the audio level of the different sources mixed into a
   common mix by a RTP mixer.  This enables a user interface to indicate
   the relative activity level of each session participant, rather than
   just being included or not based on the CSRC field.  This is a pure
   optimisations of non critical functions, and is hence OPTIONAL to
   implement.  If the header extension is implemented, it is REQUIRED
   that implementations are capable of encrypting the header extension
   according to [RFC6904] since the information contained in these
   header extensions can be considered sensitive.  It is further
   RECOMMENDED that this encryption is used, unless the encryption has
   been explicitly requested to be turned off through API or signalling.

Section 13:

   The guidelines in [RFC6562] apply when using variable bit rate (VBR)
   audio codecs such as Opus (see Section 4.3 for discussion of mandated
   audio codecs).  These guidelines in [RFC6562] also apply, but are of
   lesser importance, when using the client-to-mixer audio level header
   extensions (Section 5.2.2) or the mixer-to-client audio level header
   extensions (Section 5.2.3).  The use of the encryption of the header
   extensions are RECOMMENDED, unless there are known reasons, like
   middleboxes or third party monitoring that will greatly benefit from
   the information, and this has been expressed using API or signalling.
   If further evidence are produced to show that information leakage is
   significant from audio level indications, then use of encryption
   needs to be mandated at that time.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------