[jdev] Second-guessing dns for s2s

David Waite dwaite at gmail.com
Sat Sep 24 19:55:09 CDT 2005


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

Right - certificate chains are chains of trust, ownership of a cert is
meant as proof of identity. By trusting a CA you are saying that CA is
trusted for authentication, like how you would delegate authentication
to a LDAP within your domain.

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

I think I'm starting to come around.
- If you use dialback, you already have enough to worry about in terms
of attack vectors. The existing dialback system does nothing to
prevent DNS hijacks.
- If you use mutual SASL authentication, then I also don't believe
there is a problem - the authentication proves your identity. The
ability to do MITM via DNS hijinx seems to me to be the same as
before.

This really is something that should be submitted back to the xmpp-wg
as something to be standardized around, and not left as a flame war or
feature in a handful of servers.

-David Waite



More information about the JDev mailing list