Tjil, > 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".
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. 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. * Is a reasonable workaround given today's environment. * Is a hack that it would be great to get rid of if a better alternative can be thought of. If it's not the general community consensus that the above is true, we'll disable the algorithm by default. > 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. > 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. Regards, Matt
