On 2013-11-05 00:42, Hannes Tschofenig wrote: > > The argument that RTP is used in a number of different environments, as > a basis for not offering a solid security story is rather weak. The same > could be said about many other protocols the IETF develops, even about > TLS itself. >
I strongly disagree with that. TLS is a solution you choose to apply or not. If your RTP application is a multicast one, then we can't do DTLS-SRTP, because it is can't function in such an environment. Similar observations can be made about a number of different deployment cases. > I am wondering what motivated you write the document in this specific > style. I believe I understand the motivation for Magnus. My motivation for writing SRTP-not-mandatory document was as WG chair to not have to argue with the Security ADs each time an RTP document passed the IESG about the security sections. If you are doing an RTP extensions you need to discuss what that implies security wise and what security requirements it has. However, it is not the appropriate place to mandate a particular solution and key-management. What have been missing in IETF is to write the different "This is what you shall do, given that your RTP application class is foo". There is clearly a need for such a document for SIP established sessions. But I don't volunteer to write it. If you look at draft-ietf-mmusic-rfc2326bis, that actually normatively require anyone supporting RTP with RTSP 2.0 to implement SRTP and MIKEY based keying because that makes sense for RTSP. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: [email protected] ---------------------------------------------------------------------- _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
