RE: Rephrasing my sdescriptions query... Re: Security for RTP connections - some thoughts

["Francois Audet" <audet@xxxxxxxxxx>]

Dan,


1 - You need TLS anyways. TLS's main purpose in life is no to secure
keys in SDP. That's
    just a side effect.

2 - There are environments where you do NOT want (in fact may not be
allowed) to use
    end-to-end encryption of media stream, and where SDESCRIPTION is the
desired mechanism. 
    In fact, that would be very common in Enterprise environments.
 
So, we tell them to do both if they want to sell in both markets, or
pick the one that
corresponds to their target market.

________________________________

	From: owner-ietf-rtpsec@xxxxxxxxxxxx
[mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of dan_york@xxxxxxxxx
	Sent: Friday, March 09, 2007 11:48
	To: Alan Johnston
	Cc: ietf-rtpsec@xxxxxxxxxxxx
	Subject: Re: Rephrasing my sdescriptions query... Re: Security
for RTP connections - some thoughts
	
	

	Alan, 
	
	Yes, I'm well aware of that document and provided Dan W.
feedback on his 
	original version.  What I am still NOT clear on is where
sdescriptions with 
	TLS-encrypted SIP falls down with regard to these requirements. 
	
	> Signaling channel key agreement approaches such as SDES do not
work well 
	> with common SIP features such as forking and early media -
better 
	> security is not the only reason we are standardizing a media
path approach. 
	
	Okay, this is a good argument.  That's that type of thing I'm
trying to 
	understand - if we all wind up agreeing that ZRTP or DTLS are
the best 
	way to go... what do we as an industry say to those people out
there *today* 
	implementing TLS/SIP/sdescriptions?  Why should they move to
whichever 
	protocol we decide to use? 
	
	And if they don't see a reason to move, it means we as vendors
*still* have 
	to factor in sdescriptions as a possible SRTP key exchange
mechanism if 
	we encounter customers with existing TLS/SIP/sdescriptions
installations. 
	
	That's where I'm going with all of this, 
	Dan