A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication
RFC 6464

Note: This ballot was opened for revision 06 and is now closed.

(Gonzalo Camarillo) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-11-01 for -)
No email
send info
   "A malicious endpoint could choose to set the values in this header
   extension falsely, so as to falsely claim that audio or voice is or
   is not present.  It is not clear what could be gained by falsely
   claiming that audio is not present, but an endpoint falsely claiming
   that audio is present could perform a denial-of-service attack on an
   audio conference, so as to send silence to suppress other conference
   members' audio.  "

... you could also dominate the conversation by always claiming that you have strong audio present. 

=======

This security  consideration from the mixer to client looks like it might be applicable

2.  Furthermore, the fact that audio level values would not be
       protected even in an SRTP session might be of concern in some
       cases where the activity of a particular participant in a
       conference is confidential.  Also, as discussed in
       [I-D.perkins-avt-srtp-vbr-audio], an attacker might be able to
       infer information about the conversation, possibly with phoneme-
       level resolution.

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-11-03 for -)
No email
send info
I think Stewart's security point is valid, although I am not quite sure how this differs from simply raising your voice.

(Stephen Farrell) No Objection

Comment (2011-10-30 for -)
No email
send info
(1) If vad can expose encrypted vbr, then why don't the security
considerations here say "if encrypting vbr and doing vad then you
MUST use apply commensurate protection to both"? I don't get the
logic in the current section 6 where it says "if encrypting vbr
and doing vad then you SHOULD use some additional mechanism" -
what's the exceptional case that justifies the SHOULD there and
why would you ever do something appreciably weaker or stronger?

(2) Is the alternative to srtp-encrypted-header-ext to use IPsec or
TLS or what? It'd be better to reference those since if you don't
then I don't get how srtp-encrypted-header-ext isn't a normative
reference? I'd suggest adding a reference to either TLS or IPsec,
whichever is more likely to be used.

(Russ Housley) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2011-11-01)
No email
send info
The Security Considerations section sketches a scenario where an attacker sends high level indications, but encoded audio that is actually silent to suppress other participant's audio. A more likely attack is one that sends high level indications just to seize any speaker-selection algorithm used by a conference system.

(Sean Turner) No Objection

Comment (2011-10-31 for -)
No email
send info
I noted the same things Stephen did.