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.

(Stephen Farrell) (was Discuss) Yes

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

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (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)

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

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

(Russ Housley) No Objection

Barry Leiba No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (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.