[jdev] Second-guessing dns for s2s

[Tijl Houtbeckers]

On Sun, 25 Sep 2005 01:58:35 +0200, Matt Tucker <matt at jivesoftware.com>  
wrote:

> 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.

So basically what you're saying is.. you want to solve your problem  
(people not able to get a decent (sub)domain), and replace it with the  
problem that people can't use, for example jabber.im.example.org

So what if that's 0.1% ? Or 0.01%? What if 0.01% of all users of Firefox  
suffer from a buffer overflow. Does that mean you don't fix it?

>
> 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.

It is a "very high" security risk, because the consequences are very  
serious, for the people who are exposed to the risk. Don't compare it with  
the security risk associated with Dailback, because, as the examples  
givven to you show, that is not true.

The problem I think is, you speak of a "DNS tree". In practise, the DNS  
tree exists only 2 levels deep  
(subdomains_containing_as_many_dots_as_you_want.domainname.top). You're  
algoritim assumes differently. So if you have a server at example.org, and  
you want conference.example.org to work without having a record, you can  
do this safely. However, the person at jabber.example.org still isn't  
safe, and doesn't have any control over his situation. Basically he's at  
the mercy of whoever owns example.org. Of course he is too, right now, but  
right now the owner of example.org would have to mess with  
jabber.example.org itself, to do nasty things. With your hack, that is no  
longer needed.

So when all server run on domain.top, we're safe to use your hack.  
However, that's usually the people who ARE in the position to make  
subdomains.

>  * 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.

Security compromising hacks are rarely a "reasonably workaround" in an  
open enviroment like the internet. It's better to use one of the mentioned  
solutions; running everything on the same domain or getting some free  
subdomains from one of the many providers that do this.

> 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.

That is a very basic security misunderstanding. CA's do not provide  
security, they provide acountability.
Example: If you get a popup in your browser, which basically sais: "This  
website wants to run some code locally on your computer." and a friendly  
box from your browser telling you it's signed with a VeriSign certificate  
 from UnknownCompany, does that mean you trust this? By default? Without  
even looking??? Not even IE at the height of it's insecurity would do this  
(not even MS code!).

Compare it to giving sensitive information to a person. To make it more  
safe, you might ask them for a passport first. Does that protect the  
information you give them? Of course not. They can still tell it to the  
next person they see. But you can check if they are who they claim they  
are to you, and thus hold them accountable. You can do that by looking at  
the accountability data on the passport (eg. the name, sex, height) by  
matching this by what you already know and what you can see. Next, you  
have to trust the issuer of this passport; the goverment ("the CA"). If  
you're smart you look at the safety measures they build in (watermarkings,  
etc.), maybe you even call them up to check a serial number or something  
on the passport.

What you're doing with with dailback/sasl is just looking wether they  
*have* a passport, and if it's a real passport (well, trust the CA on  
that). You don't check if it's *their* passport, or even if the passport  
you're seeing is the passport they tried to show you. And then, just  
because they *have* one, you think it's safe to tell them sensitive  
information.

> No security is perfect, but the CA system is the bedrock of
> internet security.

For encrypting your data.

Not for trust. The CA system isn't a magic sandbox that makes everything  
safe. If I send my creditcard data over a CA signed SSL connection, that  
doesn't make whatever happens on the other end of that encrypted pipe any  
safer. I should still look at the certificate, the name/address of the  
company/person, and say, "Yes, this is the company/person that I know, and  
I trust them, not cause of some crazy certificate, but because I know and  
I trust them enough that they won't fuck up their security and have my  
creditcard details or their certificate stolen."

THAT, and trusting the CAs themself(!!), it the current "bedrock" of  
internet security. It's not at all what you propose. What you propose with  
dailback/SASL is "hey buddy, you're smart enough to buy or steal this  
certificate somewhere from a CA I like, so I'm gonna treat like I can  
trust you a lot more then those *ordinary* dailback users". You'll have  
the benefit of encryption, sure.. so people not involded witht the two of  
you will have a harder time. But that server on the other end still has  
the benifit of decryption ;) I wouldn't TRUST them any more than an  
ordinary dailback server.

What certificates *can* be used for, is as a stepping stone to develop  
more eleborate security/trust systems. When it comes to malicious attacks  
 from another server, they offer no real advantage over not using them at  
all. Well, other than that the entire attack can now be encrypted ;)  
(though man in the middle attacks can still be done, of course!)

> 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.

Well, no matter how you twist and turn, that's simply not true. What's  
true is that the "edge" cases where, you'll have to admit, the risk is  
very significant indeed, are deemed irrelevent by you (in other words:  
fuck you, edge cases). The worst thing is they can't possibly defend  
themselves from this "Jive attack", because even if they don't run it  
themselves, they are still vonurable, the flaw is on your side, not  
theirs. As for your second statement, I hope you learned enough about  
internet security today to recognize that as bullshit.