Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
RFC 6904

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

(Robert Sparks; former steering group member) Yes

Yes ( for -04)
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) Yes

Yes (2013-02-08)
No email
send info
Thanks for addressing my security-wonk concerns:-)

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (2013-02-04 for -04)
No email
send info
- Feedback from Joel Jaeggli, part of the OPS directorate, on which I would appreciate an answer:
   Section 4.1 proposes negotiating the sending of a header element in either encrypted and unecrypted 
   forms which  seems a bit self defeating. and I find it a little difficult  to stomach to say well its' important 
   that this information be encrypted, but since you can't we'll just send it in the clear. 

- Really an editorial detail. Take it or leave it.  

   A number of recent proposals for header
   extensions using the General Mechanism for RTP Header Extensions
   [RFC5285] carry information for which confidentiality could be
   desired or essential.  Notably, two recent specifications ([RFC6464]
   and [RFC6465]) carry information about per-packet sound levels of the
   media data carried in the RTP payload, and exposing this to an
   eavesdropper is unacceptable in many circumstances.

"exposing this to an eavesdropper is unacceptable in many circumstances." was not obvious to me, and I kept thinking about that one while reading through the rest of the doc.
In the end, I came back to it, and researched this: this is well described in the RFC 6464 and RFC 6465 Security Considerations.

 NEW (last sentence)
   Notably, two recent specifications ([RFC6464]
   and [RFC6465]) carry information about per-packet sound levels of the
   media data carried in the RTP payload, and exposing this to an
   eavesdropper is unacceptable in many circumstances (as described 
   in the respective RFC Security Considerations sections)

(Brian Haberman; former steering group member) No Objection

No Objection (2013-02-05 for -04)
No email
send info
I support Stephen's DISCUSS point #1.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection (2013-02-07 for -04)
No email
send info
I support Stephen's discuss and the resolutions proposed by the authors look good to me.

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -04)
No email
send info