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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------