Skip to main content

Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
draft-ietf-avtcore-srtp-encrypted-header-ext-05

Yes

(Robert Sparks)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)

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

Robert Sparks Former IESG member
Yes
Yes (for -04) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) Yes
Yes (2013-02-08) Unknown
Thanks for addressing my security-wonk concerns:-)
Adrian Farrel Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2013-02-04 for -04) Unknown
- 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 IESG member
No Objection
No Objection (2013-02-05 for -04) Unknown
I support Stephen's DISCUSS point #1.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-02-07 for -04) Unknown
I support Stephen's discuss and the resolutions proposed by the authors look good to me.
Stewart Bryant Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -04) Unknown