Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution
draft-ietf-avt-srtp-not-mandatory-16
Discuss
(Tim Polk)
Yes
(Adrian Farrel)
(Richard Barnes)
(Robert Sparks)
No Objection
(Alexey Melnikov)
(Gonzalo Camarillo)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
Note: This ballot was opened for revision 08 and is now closed.
Dan Romascanu Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2010-08-24)
Unknown
This document does a good job in building the case that SRTP is not universally fit as a security solution for all use cases of RTP. I have however a couple of issues with two sections in the document that I would like to be discussed before I can approve the document: 1. The last application scenario listed in Section 3 says: > Finally, the link layer may be secure, and it may be known that the RTP media data is constrained to that single link (for example, when operating in a studio environment, with physical link security). An environment like this is inherently constrained, but might avoid the need for application, transport, or network layer media security. I do not believe that this is relevant in a discussion about securing an IETF protocol. BCP 61 (RFC 3365) Section 6 is very clear in that: > One of the continuing arguments we hear against building security into protocols is the argument that a given protocol is intended only for use in "protected" environments where security will not be an issue. ... The solution is that we MUST implement strong security in all protocols to provide for the all too frequent day when the protocol comes into widespread use in the global Internet. I suggest to take out this case as irrelevant 2. I am confused about what section 5 tries to say. First I do not know the term 'framework protocol' - this needs to be defined or referred to. What the section seems to say is that for that category of protocols (where RTP belongs) the strong security is more an application issue, where an application may be built of several building blocks, out of which the protocol is only one of them. This seems again to question or even justify an extemption from the requirements of BCP 61 [RFC3365] for RTP or even a whole class of protocols.
Tim Polk Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2010-08-26)
Unknown
Note: This is a joint discuss from both Security ADs. Given the importance of this document, we are both holding a discuss position so we can participate in the discussion that follows. We accept the basic premise of this document: as a “framework protocol”, applying BCP 61 directly and mandating a single security solution is not appropriate and would not achieve the goal of BCP 61: ensuring that security mechanisms are implemented (and thus available) even if it is not turned on in every deployment. However, we do not believe the proposed solution (leaving the selection to each application of RTP) is any more likely to achieve that goal. In most actual deployments, RTP is basically not secured. Allowing a thousand flowers to bloom practically guarantees that real deployments will not include security mechanisms (since there is so little prospect of code re-use and many current deployments won’t turn it on.) To meet the spirit of BCP 61, we recommend that the working group consider the following approach: specify a small set of solutions that cover the major classes of applications, and mandate implementation of the appropriate solution for each RTP application. RTP application standards would be required to justify a mandatory to implement security scheme that does not fall within this set. We believe this solution provides the best opportunity to achieve the goals of BCP 61 for RTP-based applications.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
(2010-08-24)
Unknown
This is a very much needed document, well written, and makes IMO the right conclusions. I did have two issues, however, but decided to place a Yes vote as opposed to holding a discuss. I do want to talk about these topics on the IESG telechat, however. The first issue is that in Section 4 MIKEY is ruled out as mechanism for supporting situations where the SIP infrastructure is untrusted. I do not understand why this is being done. MIKEY can provide end-to-end authentication, which would seem to thwart attacks where SDES would clearly fail. Can this exclusion be elaborated and/or removed? The second issue relates to the main recommendations. The documents makes the argument that RTP applications are so diverse that they can not live under the same security solution. However, I am left wondering whether there would be mandatory-to-implement security solutions for specific applications. Do the authors for some reason believe that is not feasible or undesirable? Should there be IETF activities started on making such requirements for specific applications?
Richard Barnes Former IESG member
Yes
Yes
(for -14)
Unknown
Robert Sparks Former IESG member
Yes
Yes
()
Unknown
Stephen Farrell Former IESG member
(was Discuss)
Yes
Yes
(2012-11-19 for -11)
Unknown
Many many thanks for working through this. We finally got it!
Alexey Melnikov Former IESG member
No Objection
No Objection
()
Unknown
David Harrington Former IESG member
No Objection
No Objection
(2010-08-25)
Unknown
I support Russ's DISCUSS
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2010-08-23)
Unknown
Section 3., paragraph 4: > [ETSI.TS.102.474], where one mode of operation uses ISMAcryp > (http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP > payload data only. Nit: It'd be better to refer to this URL as a reference. Section 4., paragraph 9: > authentication solutions that are tied into the key manangement. Nit: s/manangement./management./
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(for -09)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2012-11-20 for -11)
Unknown
I cleared. Thank you for working through this.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown