[jdev] Second-guessing dns for s2s

[David Waite]

The major problem with this sort of second-guessing DNS isn't even the
security problems it possesses (by assuming that DNS nesting MUST
imply some sort of trust relationship of services running under those
names).

It is that servers which implement the XMPP standard and which don't
add this DNS hack will not be able to contact all the services someone
may if they are also running under Jive.

-DW

On 9/24/05, Tijl Houtbeckers <thoutbeckers at splendo.com> wrote:
> On Sat, 24 Sep 2005 17:59:00 +0200, Peter Millard <pgmillard at gmail.com>
> wrote:
>
> > On 9/22/05, Tijl Houtbeckers <thoutbeckers at splendo.com> wrote:
> >> On Thu, 22 Sep 2005 22:53:20 +0200, JD Conley <jd.conley at coversant.net>
> >> wrote:
> >>
> >> >>
> >> >> This is bad engineering i.t.o. creating undesirable impact on the
> >> > broader
> >> >> Internet.
> >> >
> >> > What is the undesirable impact? .
> >>
> >> It is, at least, a minor security risk.
> >
> > I disagree that this is a minor security hole.
>
> I did say at least ;)
>
> > The fact that my JM
> > server can potentially contact two completely different servers for
> > the same JID is a very bad thing. Jabber ID's are designed to be
> > unique, and they should be. This uniqueness is provided by using
> > domain names to help partition off the namespace. What you are
> > essentially doing is flattening this namespace by changing your
> > implementation.
> >
> > ie, when my server contacts foo at conference.jabber.org, it should
> > NEVER, EVER, try to send that message to foo at jabber.org instead. This
> > seems very bad to me.
>
> well I assume it still send it to foo at conference.jabber.org, just over a
> connection to jabber.org. So a decent non-malicious server would reject
> the stanza, and at least never deliver it to foo at jabber.org.
>
> Because of the way in general DNS is implemented and used on the internet
> the risk is not as bad as you'd first think. But it certainly opens up a
> few attack angles.  The biggest benifit for attackers would be that a DNS
> attack will become more stealthy. Instead of changing/spoofing the DNS
> entry the server uses itself, which is very noticeable, you can steal
> entry one higher in this (completly unrelated to DNS, except for the last
> two "dots" in the address) hierachy. So if you run your Jabber server on
> jabber.services.example.org I can steal services.example.org. An entry
> that might not even be used or exist!
>
> Wether it's a minor, severe, or critical risk, you don't activly work to
> create a security flaw, in my opinion.
>
> Is there anything preventing a person (other than lack of servers who
> support this) to run conferencing or transports or anything at the same
> domain as the server? The only bad thing I see is you can't make
> channels/transport entries that conflict with users on the server. That's
> problem that should be solveable (eg. go IRC style and add a # for
> channels, and disallow usernames starting with with #). There might be a
> disco/identity problem, but why wouldn't a server be able to have multiple
> identities? Does protocol prohibit this? If so we're better off changing
> that, than creating security holes.
>