Skip to main content

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 steering group member) Yes

Yes (for -14)

                            

(Richard Barnes; former steering group member) Yes

Yes (for -14)

                            

(Sean Turner; former steering group member) Yes

Yes (2013-12-19 for -14)
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 steering group member) Yes

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

(Adrian Farrel; former steering group member) No Objection

No Objection (2013-12-16 for -14)
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 steering group member) No Objection

No Objection (for -14)

                            

(Benoît Claise; former steering group member) (was Discuss) No Objection

No Objection (2014-01-16)
Thank you for addressing my DISCUSS

(Brian Haberman; former steering group member) No Objection

No Objection (for -14)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -14)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (2013-12-18 for -14)
I await the arrival of

draft-ietf-avt-srtp-a-really-good-idea-and-heres-how-for-your-usage

(Stephen Farrell; former steering group member) No Objection

No Objection (2013-12-19 for -14)
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 steering group member) No Objection

No Objection (for -14)

                            

(Ted Lemon; former steering group member) No Objection

No Objection (for -14)