[jdev] Second-guessing dns for s2s

[Tijl Houtbeckers]

On Sun, 25 Sep 2005 00:33:11 +0200, Matt Tucker <matt at jivesoftware.com>  
wrote:

> Assume your server is down so some Jive Messenger instance tries to make
> the connection to dyndns.org. If an evil XMPP server truly lives at that
> address, how could you possibly trust that your dynamic DNS entry is
> also valid? Can anyone come up with a real example of this DNS attack
> being a greater vulnerability than standard dialback?

I did that in my first reply, the other problem I pointed out was in my  
last reply; Instead of having to steal the DNS record you can "steal" one  
that's hardly used or doesn't even exist. This gives attacks a lot more  
"stealth".

> So, dialback itself. I think it provides good security for most users.
> However, dialback + TLS doesn't seem to be implemented by any servers
> yet. We're going to create an implementation for Jive Messenger because
> we think it offers a great mix of security and ease of use. The most
> common secure s2s mechanism we've found so far is dialback + SASL
> external. For security, it's pretty much critical that the certificate
> presented through SASL external be signed by a CA. We're just completing
> our TLS + SASL external implementation now and will likely support all
> the major CA's by default. Based on many threads on this mailing list
> I'd also like to support certs signed by CACert.org by default. Anyway,
> assuming that servers are using TLS + SASL external, even a DNS attack
> wouldn't compromise the security of the Jive Messenger algorithm -- they
> would also need to subvert the CA cert signing process.

While requiring a signed certificate is a step up, it is only a small step  
it. It are still unknown servers you are talking to, thus unknown  
certificates. Certificates can and have been stolen in the past, they are  
only very trustworthy if you *know* who you're talking to, and then,  
likely, you wouldn't even do dailback. You might do some caching of  
certificates, but what *if* the server you were talking to suddenly has a  
different certificate? Is that a good reason to reject the s2s connection?  
(what if their last cert expired? what if they changed CA's? etc.)

So unfortunatly, even with TLS this method still introduces a security  
flaw. Wether it's a minor one not, we can debate about it all day, but any  
security flaw like this is SERIOUS. No matter how bad you want a feature,  
compromising security is not the right answer.

If we're talking about "dyndns" type services anyway, why don't users get  
a bunch of accounts for the different entries? (in fact, most service  
providers would probably support a wildcard). If you don't own the domain  
you use for your server anyway, you might as well use something like that  
for conferencing or transports.