[jdev] [ANN] Google Talk engineering manager live chat

[Richard Dobson]

> > Not really, if you use the example of SMTP you cant run two
> > entirely different email services on the same domain.

> Just because a lot of server developers think of MUC and standard c2s as
> two different components doesn't mean that users do. In fact, it's
> exactly the opposite. Here's an example from the email world -- a few
> organizations setup pop.example.com and smtp.example.com so that they
> have more flexibility about where different parts of email traffic go.

Sorry but that is a bit of an erroneous comparison, in the cases where orgs 
setup pop.example.com smtp.example.com etc they are not providing extra 
email addresses of user at pop.example.com and user at smtp.example.com they are 
just pointing to the same server that is providing emails for 
user at example.com, in the case of XMPP where you have a MUC component 
connected to a host XMPP server the MUC component in current implementations 
has its own domain separate from any other domains the server hosts.

> However, the vast, vast majority of companies will just install a single
> email server at one domain that does both sending and receiving of
> email. That's because users and admins think of "email" as a unified
> service for sending and receiving messages. It's the same thing for
> services like MUC. Admins want to setup an "IM system" and shouldn't
> have to care about all the different services and the required DNS
> entries.

If you want to run a MUC service on its own domain then you have to setup 
the DNS entries, if you dont want to have to setup those entries then follow 
my suggestion and run all your XMPP services on the same domain rather than 
separate ones, other than the possible overlaps it should be fine (although 
they can be solved by just using something like prefixing).

> So, let's say you have the choice between two IM systems. One you can
> double click an exe, wait 5 minutes and then it all "just works".

What IM system would this be?, I find it hard to believe any IM system is 
going to be externally connectable without some kind of DNS entries being 
setup.

> The
> other IM system has 5 different sub-components. You'll have to fill out
> paperwork for each one because they require a new subdomain and new
> subdomains are handled by the IT department at your org and will take
> two weeks to setup. Which IM system do you go with? :) For you, a
> subdomain is "no problem", but this is honestly not the situation at a
> lot of orgs.

Then follow the suggestion of implementing all the server component under a 
single domain if thats what they want, rather than individual sub domains, 
simple and doesnt require any non standard hacks, as it has been said if 
there are any problems with this approach its better to perfect the single 
domain approach than perpetuate a "hack" that has some potential security 
implications.

> Yep, you've pointed out exactly why subdomains are required. Quite
> simply, this is a design flaw of the XMPP protocol.

Not really, its just the recommended way to set it up (avoids any namespace 
overlaps, i.e. a room overlapping a user with the same name), as far as I 
can see it you should be able to run a conference server under the same 
domain as c2s, you should easily be able to run stuff like pubsub under it 
too.

> I still haven't heard a lot input about why the logic we've implemented
> in Jive Messenger is a bad thing other than "it's not normal". The only
> argument so far is that if you are on "blah.foo.com", your server goes
> down, and there's an evil server on "foo.com" that wants to
> transparently take your IM traffic then you'd be in trouble. This is a
> logically true argument, but I think the enhanced ease of use of
> outweighs this practically non-existant security concern.

Its not non existant at all, at the very least it provides a way for an 
attacker to compromise your entire XMPP setup by highjacking a single point 
of your DNS setup, at worse they can compromise an organisation unrelated to 
your own and highjack your traffic, thats hardly a non-existant security 
concern, IMO we shouldnt be working to introduce any security concerns 
wether they are serious or not anyway, if anything we should do everything 
we can do to make it more secure, not less.

But anyway I doubt you will change your view on this subject, I just hope 
you will provide your users with a way to turn off this "feature" just 
incase they arnt happy with the security concerns it introduces.

Richard