Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------