Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
RFC 6904
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Robert Sparks; former steering group member) Yes
(Stephen Farrell; former steering group member) (was Discuss) Yes
Thanks for addressing my security-wonk concerns:-)
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
- 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
I support Stephen's DISCUSS point #1.
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I support Stephen's discuss and the resolutions proposed by the authors look good to me.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection