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

[Mark Baugher <mbaugher at cisco.com>]

On Aug 14, 2004, at 10:01 AM, Eric Rescorla wrote:

> Mark Baugher <mbaugher at cisco.com> wrote:
>
> > Hi Mats
> >     Your point is well taken about decoupling SRTP from key
> >     management, which varies from pairwise key management using (say)
> >     IKE or MIKEY to broadcast key management using subset difference.
> >     I don't think DTLS has much relevance to AVT protocols and am
> >     copying the authors and security ADs to check my reasoning.
> >     SSL/TLS has been successfully deployed for a class of
> >     client/server applications.  That is outstanding.  It has some
> >     vulnerabilities, however, that have been exploited by phishing
> >     attacks, which is bad.
>
> Phishing is a social attack, not an attack on anything specific
> to SSL.

Phishing might use more than social engineering, there's a class
attack against browsers that wrongly route requests such as
http://www.example.com/some-other-address to some-other-address
and not to example.com.  The URI comes from a message with a forged
RFC 2822 from address with example.com as the domain part.  The
machine at some-other-address is own3d by an attacker, who posts
a web page that looks like an www.example.com registration web page.
So far, no SSL is involved in the attack.  It may not be
needed to fool many users who usually expect the server to
initiate the session and authenticate _them_ rather than vice
versa.  I guess this is a social attack, but it's made possible
because of the nature of the global security system that uses SSL.
It relies on natural language names and asymmetric authorization/
authentication where the server typically initiates the secure
session and then gets much more information from the client than
the client gets from the server.  The security problems with
natural language names are considered in section 2 of RFC 2693;
the problem of asymmetric authorization has been discussed in
Risks and other places.

> It would work just as well against, say, HTTP over IPsec.

It depends on the authorization and credential system, doesn't
it?
> >     But regardless of the pros and cons of
> >     SSL/TLS vs. IPsec, RTP has many peer-to-peer applications.  I
> >     think that IPsec and/or SRTP can adequately protect almost any
> >     real-time RTP session between peers or between clients and server.
> >     I can't think of anything DTLS will do for AVT protocols beyond
> >     adding an unneeded alternative - and the accompanying confusion -
> >     to the mix.
> >
> >    http://www.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt
> >    should probably specifically state that it is not appropriate for
> >    the RTP family of protocols.
>
> I don't understand the argument here. Unless there's some technical
> reason why DTLS won't work for these applications, I don't understand
> why the existence of alternative mechnisms requires a statement
> that DTLS is inappropriate...

Today, there are two practical alternatives for securing SRTP and
these are IPsec and SRTP.  I think we satisfy the concerns of
[WHYIPSEC] that are mentioned in draft-rescorla-dtls-01.txt.  Is it
generally true that having two security protocol alternatives is better
than three for reasons of relative simplicity of the implementations,
improved interoperability, and lower development/maintenance costs.
Why would we add a 3rd protocol?  What does DTLS offer over the other
two?

Mark
> -Ekr


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