[jdev] Second-guessing dns for s2s

[Matt Tucker]

Hey all,

We take security issues very seriously and appreciate the feedback.
However, some of the reactions in this thread are simply unreasonable.
Why do so many JSF discussions wax into flame wars? :)

So, I'd like to take a step back and try to step through the issues.
First, unless there's an evil XMPP server, you'll never run into
problems. Servers are required to reject stream connections for domains
that they don't control. So, if "example.blah.com" isn't controlled by
the XMPP server "blah.com", than an s2s connection for that subdomain
will be rejected.

Now, let's consider the case of an evil XMPP server. If somebody has
managed to subvert your DNS tree, you're pretty much already screwed.
Why wouldn't they just take over DNS of your normal server address? Even
those of you that use dyndns and other such services where you don't
control the full tree are in the same boat. Let's take the example:

 someuser.dyndns.org

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? If you don't trust
your DNS tree, I would argue that the security of dialback is already
compromised.

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.

> I disagree that this is a minor security hole. The fact that 
> my JM server can potentially contact two completely different 
> servers for the same JID is a very bad thing. Jabber ID's are 
> designed to be unique, and they should be. This uniqueness is 
> provided by using domain names to help partition off the 
> namespace. What you are essentially doing is flattening this 
> namespace by changing your implementation.
> 
> ie, when my server contacts foo at conference.jabber.org, it 
> should NEVER, EVER, try to send that message to 
> foo at jabber.org instead. This seems very bad to me.

Umm, I think you misunderstand. Actually what happens is that the JM
instance will connect to jabber.org but attempt to send the packet to
foo at conference.jabber.org. JID uniqueness is never violated.

>From David Waite:

> It is that servers which implement the XMPP standard and which don't
add 
> this DNS hack will not be able to contact all the services someone may
if 
> they are also running under Jive.

We still tell users to make the DNS entries for compatibility with other
servers. But, a good example of when users might not bother to make the
DNS entries when using JM is when they want to connect multiple XMPP
servers together but only inside their org (east-coast.example.com,
west-coast.example.com, etc).

Regards,
Matt