[jdev] Second-guessing dns for s2s

[Johannes Fröhlich]

On 9/25/05, Matt Tucker <matt at jivesoftware.com> wrote:
> 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
>

Hmm. I didn't read the specs or jeps fully yet but mainaining a jabber server.
I agree with Matt that it's a bummer how jids are constructed. But my suggestion
would be to make it as consistant as possible for the user. As a user
I know that
a jid is "username at server.net". And from this view I can browse for services on
the server "server.net".

My suggestion would be to list services like "server.net/service".
This would be a
resource for the server. A muc-room would be "server.net/muc/room" and
a user using
this mucroom would have the jid "user at server.net/muc/room" or
just "user at server/room".

Just an idea.

--
-- Johannes