Re: [AVT] Comments on "SRTP Not Mandatory" (draft-perkins-avt-srtp-not-mandatory-01.txt)

[Colin Perkins <[e-mail]>]

Dan,

[Coming back to this very late...]

On 28 Jul 2008, at 21:31, Dan York wrote:
> Colin,
>
> A few comments on http://tools.ietf.org/id/draft-perkins-avt-srtp- 
> not-mandatory-01.txt . First, one caveat: I have not been (but am  
> now) a subscriber to the AVT mailing list and so I did not see any  
> of the previous discussion on this draft. The first I knew of it  
> was the Dublin agenda and the discussion today.  Having said that,  
> when I search the list archives (using Gmane.org) I can't seem to  
> find any strong discussion on the list.
>
> Comments:
>
> 1. It's not entirely clear to me WHY this draft is necessary.  I  
> heard Cullen's comments today that this would make all of our lives  
> easier as draft authors and have seen Colin's post here: http:// 
> article.gmane.org/gmane.ietf.avt/8084/ Is the issue really that we  
> essentially need a FAQ about SRTP/RTP?

Yes - this has actually been very problematic when trying to get  
drafts approved by the IESG.

> 2. The section on RTP Applications and Deployment Scenarios is  
> nicely done.
>
> 3. In section 3 in the second paragraph, I would suggest a better  
> example is necessary to demonstrate media security solutions other  
> than SRTP than the example using a single TCP connection.  In that  
> example, TLS is being used to encrypt the *entire* SIP and media  
> connections.  Effectively creating a TLS tunnel and putting all the  
> SIP and media traffic through it.  A similar example could be given  
> with IPSec.  In both cases, though, I would argue that they are NOT  
> doing something special with RTP... they are encrypting the entire  
> channel and *nothing* is being done specific to RTP.
>
> To put it another way, the example does NOT convince me that SRTP  
> could not be mandatory *when a security solution is required for  
> RTP*.  In this example of TLS encrypting the entire channel, RTP  
> "security" could simply be turned off as there is no need for it.
>
> 4. Similarly, in the third paragraph of section 3, the example of  
> the secure link layer does not convince me that SRTP could not be  
> mandated as again, it is a situation where doing something to the  
> RTP protocol is not required because the underlying transport  
> mechanism is secure.

Agreed. The main point, though, is that the answer for media security  
is not "just use SRTP", it's "use SRTP, unless...", and this draft is  
trying to explain that the "unless" will always exist.

> 5. In section 4, "Implications for Key Management", I understand  
> that you are trying to make the point that there are a wide range  
> of options out there, but the reality that I am seeing out there in  
> the market is that there is only really *one* SRTP key management  
> protocol deployed in any meaningful way... "sdescriptions".  I've  
> heard of a few pre-standard DTLS-SRTP efforts and there are  
> certainly some ZRTP implementations in a few products, but beyond  
> that I've not seen any serious usage of any of the other mechanisms  
> listed.  (I'd love to hear otherwise from others on the list.)  We  
> beat this whole issue up in a whole range of RTPSEC BOFs over the  
> course of a number of IETF meetings.
>
> I know you reference draft-ietf-sip-media-security-requirements  
> (which is now up to -07) which defines the requirements for key  
> exchange protocols, but I would suggest that this draft should  
> reflect a bit more closely the actual SRTP usage out there and  
> mention the convergence toward two primary protocols (sdescriptions  
> and DTLS-SRTP) with another one (ZRTP) out in the market as well.

Those protocols are very closely tied to unicast telephony and  
conferencing, whereas this draft is considering the full range of RTP  
use case. I'd prefer this draft to simply point out that there are a  
range of keying protocols, and not recommend any of them. I'll try to  
clarify in the coming revision.

> 6. In section 5 and 6, I guess maybe I'm looking at this a bit  
> differently.  The document indicates there are cases where SRTP  
> makes sense to be used - and there are cases where NO modifications  
> to RTP are necessary.  So it seems to me that you could break RTP  
> encryption out into two cases:
>
>   A. TRANSPORT PROTECTION EXISTS - Either through other encryption  
> mechanisms like TLS or IPSec or physical mechanisms such as  
> dedicated physical channels.  In this case, no special security is  
> used for RTP and plain old RTP is sent across the protected transport.
>
>   B. NO TRANSPORT PROTECTION EXISTS - Use SRTP.
>
> I've not seen any other suggestions for security mechanisms that  
> modify the RTP beyond SRTP.  Are there any others being proposed?

There are likely still users of the basic encryption specified in RFC  
1889. I'm not aware of any other proposals.

> With this in mind, I would suggest that we could summarize it more  
> as that you have two options for securing RTP: 1) using a security  
> mechanism that protects the transport of the RTP and allows the RTP  
> to pass unaltered; or 2) use SRTP if you can't (or don't want to)  
> secure the underlying transport.
>
> 7. Based on what I said in my #5 above, I would disagree with the  
> final sentence of section 6, the Conclusion: "Currently is is much  
> harder to point out a preferred key-management solution."   As  
> stated earlier, pretty much everyone I know of right now who is  
> doing SRTP is using sdescriptions as the key management solution.   
> After pounding through 13+ proposals in the RTPSEC BOF, the  
> direction of the IETF is very clearly on DTLS-SRTP as "the way  
> forward".  I would suggest that this should be mentioned in some  
> manner.
>
> 8. NITS - Two minor ones:
>
>    a. Last sentence of last paragraph in section 5... "with an  
> option of turining on" should obviously be "turning".
>
>    b. First paragraph of section 6, second sentence... "In the  
> absense..." should be "absence".
>
>
> I'm not saying that we shouldn't have this draft. I understand that  
> there is a need to explain why we just don't mandate SRTP  
> everywhere.  But I also think we should promote/recommend that SRTP  
> be used wherever transport protection isn't available and should  
> also promote/recommend the paths that we see for the SRTP key  
> exchange going forward.

My working draft now states "SRTP is a preferred solution for the  
protection of the RTP traffic in those use cases where it is  
applicable.  It is out of scope for this memo to recommend a  
preferred key management solution."

Cheers,
-- 
Colin Perkins
http://csperkins.org/



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt