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