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

[Eric Rescorla <ekr at rtfm.com>]

Mark Baugher <mbaugher at cisco.com> wrote:

> 
> 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.

All of which would be true with, say, HTTP over IPsec.  Moreover SSL
offers certificate-based client authentication, so it's perfectly
possible to avert this attack using mechanisms already present
in SSL.


> > It would work just as well against, say, HTTP over IPsec.
> 
> It depends on the authorization and credential system, doesn't
> it?

In some theoretical sense, I suppose. In practice, any HTTP over
IPsec system that anyone would be likely use would have similar
properties.


> >>     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?

Are you suggesting that a generic datagram security mechanism is a 
bad thing? 


-Ekr

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