Re: [AVT] Fwd: [Tsvwg] Looking for feedback on DTLS

[Mark Baugher <mbaugher at cisco.com>]

On Aug 16, 2004, at 5:46 AM, Lee Dilkie wrote:
> Both IPsec and SRTP have shortcomings. IPsec is unable to provide the 
> flexability and deployability required for RTP. SRTP lacks any key 
> exchange/authentication (which I'm grateful for, BTW). DTLS gives the 
> flexability of TLS (being tied to host names instead of IP addresses 
> is a big plus over IPsec), the security of TLS (the most deployed 
> security solution out there) and over a UDP transport, something we've 
> been needing for a long time now.

I'm skeptical that encapsulating RTP in DTLS will result in faster or 
wider deployment of RTP security.  The wider deployment of SSL over 
IPsec has more to do with the applications they service than the 
protocols IMHO.  Most people use IPsec for VPN and SSL for web 
transactions.  I personally expect that TLS, when used for VPNs, will 
encounter similar interoperability problems as IPsec since certain 
operations have not been standardized, such as configuring a host with 
VPN addresses.  Not having a standard causes interoperability problems 
and so might having too many alternative standards.  That's my concern. 
 I read http://www.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt 
and learned that DTLS is motivated by the fact that (1) IPsec is not 
suitable for all applications and (2) application-specific security 
solutions are hard to develop and time consuming.  We have already done 
(2), so I question the value of DTLS for RTP.

On Aug 16, 2004, at 2:04 AM, philippe.gentric at philips.com wrote:
<...>
> As I mentionned above one key feature for scalable streaming
> is "encrypt once distribute many times",

Yes. We know that because we developed the ISMA 1.0 Authentication and 
Encryption protocol together for "pre-encrypted" media.  I hear 3GPP 
did a second protocol.  Before a third body comes along and does it 
again, perhaps one of the groups should bring their protocol to the 
IETF, which I consider as being "official."  As you point out, all we 
have today is transport-level authentication and encryption that cannot 
support "pre-encryption."  DTLS does not change that; it's yet another 
way to do transport security.

On Aug 16, 2004, at 1:45 AM, Colin Perkins wrote:
<...>
> In forwarding the draft, I was hoping the working group could discuss 
> that very question, rather than dismissing the DTLS work out of hand. 
> We have a charter item to work on RTP over TCP/TLS, and I would 
> consider alternative RTP security mechanisms (in addition to SRTP and 
> IPsec) to be explicitly within our scope.

I think I've made my opinion known and hope I'm not dismissing it out 
of hand.  If we did not have SRTP, DTLS would be a lot more interesting 
to me.  But DTLS will undoubtedly need to be specialized for real-time 
media so there is this task in addition to the task of 
developing/deploying DTLS.  I can't explain why we would undertake this 
effort for web servers that stream media instead of recommending MIKEY 
with SDP key management extensions or TLS with sdescriptions.  In a VPN 
environment, IPsec with IKE is already used.  Do you think working on 
more alternatives is needed or helpful to deployment and 
interoperability?  Maybe there will be great synergy with DTLS and 
future RTP work on TCP/TLS that will simplify RTP security to a single 
TLS-based protocol.  I kind of doubt that.

Mark


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt