> 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 "[EMAIL PROTECTED]", 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 [EMAIL PROTECTED], [EMAIL PROTECTED] isn't anyone at all related to [EMAIL PROTECTED] 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/
