[jdev] Second-guessing dns for s2s

[Perry Lorier]

> Are you playing devil's advocate or are you serious? If I had to guess,
> I'd say that 99.9% of public XMPP servers are deployed at [domain].com
> or [sub].[domain].com. They're not deployed at
> [sub].[sub].[sub].[domain].com. This means that there are generally
> never "unused" or "hardly used" domains up the tree from any particular
> XMPP server that somebody could stealthily take over.

We run our conference server on conference.jabber.meta.net.nz.  This is
a sub.sub.sub.domain.nz, and is probably very common for companies using
jabber outside the US where their domain is in a CC TLD.

> What I'd love to see is that people generally agree that this algorithm:
> 
>  * Is a miniscule security risk beyond standard dial-back. If you can't
> trust your DNS tree, you can't trust dial-back.

Perhaps a little aside here, IE looks up http://wpad to try and auto
discover a proxy.  This means it tends to walk up the DNS tree of the
host of the machine to find "wpad.somedomain".

This meant Microsoft had to issue a patch to fix it (
http://www.microsoft.com/technet/security/bulletin/ms99-054.mspx ).
There are a lot of people that don't have this patch applied. You seem
to be suggesting the same thing.

What happens if I register _tcp.com ?

>  * Is a reasonable workaround given today's environment.

If you can't afford to go buy a domain name that you fully control to
run your jabber server under, then what kind of quality to end users are
you going to be able to provide?  This may be useful in a test
environment, but not on the production Internet.

>  * Is a hack that it would be great to get rid of if a better
> alternative can be thought of.

Buy a domain name, or get control of a subdomain of one?

> If it's not the general community consensus that the above is true,
> we'll disable the algorithm by default.

This opens a can of worms.  I occasionally write transports/bots for
xmpp.  I might convince a server admin to delegate me say
"nifty.jabber.org".  Now one day you might want to talk to
"foo at nifty.jabber.org", but due to a hiccup on the Internet, the DNS
fails to resolve (maybe someone walked in front of your wireless card
just as you were doing the lookup).  Now you start sending messages to
jabber.org.  You are relying on jabber.org to reject those messages.
But say that the jabber.org admins are feeling evil, (or even just a bug
in their software), now the message gets delivered to foo at jabber.org,
foo at jabber.org isn't anyone at all related to foo at nifty.jabber.org.

And before you say that "the server shouldn't do this", think about a
server that's configured to listen to *.jabber.org, it's a potentially
useful feature.  Lots of people actually do this for webservers then
rely on DNS to not send people to the server if the domain doesn't
exist, why would this idiom not be used in the jabber world?

You've replaced two security systems (my machine shouldn't be sending
messages to jabber.org at all and jabber.org should reject them even if
it does) with only one.  The more layers of security you have the more
secure you are.

>>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.
> 
> 
> That's the point of a CA. If a CA signs a cert, that means you should
> trust it. No security is perfect, but the CA system is the bedrock of
> internet security. I don't particularly like how the CA system works,
> but that's another issue.

So you can't get a subdomain (for $20 or so[1]), but I can get a SSL
Cert for ~$1000?[2].  It's not that you can't run services, coz you're
running a jabber server? What is the problem you're trying to solve here?

> 
>>No matter how bad you want a feature, compromising security 
>>is not the right answer.
> 
> 
> I disagree. Nothing is a black and white issue -- features always have
> to be weighed against security. Many people won't go sky diving, but
> most feel reasonably safe driving a car despite the fact that tens of
> thousands die each year in car wrecks. For ultimate safety, s2s should
> just be disabled. :) In our opinion, our DNS algorithm isn't a
> significant risk beyond what you get with standard dial-back and is a
> virtually non-existent risk if you do decide to require CA certs for s2s
> connections.
> 
> If people generally agree with all of the above, then hopefully we can
> move on to discussing alternatives to sub-domains further.

Why not just use wildcard DNS to achieve what you want to do?

[1]: http://networksolutions.com/

[2] http://www.verisign.com/