Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution
draft-ietf-avt-srtp-not-mandatory-16
Yes
(Martin Stiemerling)
(Richard Barnes)
No Objection
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Stewart Bryant)
(Ted Lemon)
Note: This ballot was opened for revision 14 and is now closed.
Martin Stiemerling Former IESG member
Yes
Yes
(for -14)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(for -14)
Unknown
Sean Turner Former IESG member
Yes
Yes
(2013-12-19 for -14)
Unknown
I know this has been a long time in the making. I have to admit I've never loved the idea of no MTI but we seem to do it for other protocols like HTTP, Oauth, eMail, and the list goes on. My assumptions here are 1) there won't be whole lotta these profiles coming our way, and 2) implementers actually want to have *secure* interoperable solutions. The Security Considerations really is: This entire memo is about mandatory to implement security or the lack thereof for RTP.
Spencer Dawkins Former IESG member
Yes
Yes
(2013-12-17 for -14)
Unknown
I appreciate the work that has gone into this doc. Thank you for seeing it through.
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-12-16 for -14)
Unknown
I am not quite comfortable with the discussion of interoperability. I do buy the argument of the document, but I don't see how, when I buy or implement RTP for one of the deployment or application scenarios listed in section 2, I end up with the right strong security. I believe the way to handle this is to describe for each of the cases in Section 2 what security is expected in any implementation. In that way, there is something to do a cross-check against, and interoperability is more likely. I'll leave this as a Comment and hope that the authors pick up on it and work through it with someone who has more clue than I do about the needs of interop and MTI security.
Barry Leiba Former IESG member
No Objection
No Objection
(for -14)
Unknown
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2014-01-16)
Unknown
Thank you for addressing my DISCUSS
Brian Haberman Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -14)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2013-12-18 for -14)
Unknown
I await the arrival of draft-ietf-avt-srtp-a-really-good-idea-and-heres-how-for-your-usage
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-12-19 for -14)
Unknown
Thanks for working this through over >1 generation of security AD. Do you really need this bit: For a framework protocol, it appears that the only sensible solution to the strong security requirement of [RFC3365] is to develop and use building blocks for the basic security services of confidentiality, integrity protection, authorisation, authentication, and so on. When new uses for the framework protocol arise, they need to be studied to determine if the existing security building blocks can satisfy the requirements, or if new building blocks need to be developed. A mandatory to implement set of security building blocks can then be specified for that usage scenario of the framework. I'm concerned that composition like that could result in insecurity. I think I'd prefer you to delete this and the following para.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -14)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -14)
Unknown