Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution

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

(Richard Barnes) Yes

(Spencer Dawkins) Yes

Comment (2013-12-17 for -14)
No email
send info
I appreciate the work that has gone into this doc. Thank you for seeing it through.

(Martin Stiemerling) Yes

(Sean Turner) Yes

Comment (2013-12-19 for -14)
No email
send info
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.

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2014-01-16)
No email
send info
Thank you for addressing my DISCUSS

(Adrian Farrel) No Objection

Comment (2013-12-16 for -14)
No email
send info
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 

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.

(Stephen Farrell) No Objection

Comment (2013-12-19 for -14)
No email
send info
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.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2013-12-18 for -14)
No email
send info
I await the arrival of


Barry Leiba No Objection

(Ted Lemon) No Objection