[Standards-JIG] proto-JEP: Smart Presence Distribution

Pedro Melo melo at co.sapo.pt
Wed May 17 23:06:50 UTC 2006


On May 17, 2006, at 11:20 PM, Tijl Houtbeckers wrote:

> On Thu, 18 May 2006 00:02:21 +0200, Pedro Melo <melo at co.sapo.pt>  
> wrote:
>> So basically the problem of keeping the rosters in sync is not a  
>> problem with this proto-jep, but a problem that we already have  
>> today.
> No. What your roster looks like is your own responsibility. If you  
> want it to be out of sync or incorrect, fine. You want to write  
> JEPs to decrease the chances of that happening, fine, go ahead.  
> *That* is not related to what we're talking about here.

Exactly my point: the fact of the rosters being in sync or not is not  
related to this JEP. This JEP assumes that they are, just that.

And btw, what the rosters looks like is not my responsibility alone.  
The other parties have a lot of influence on that one.

> What your proposol does is allow people with an *incorrect* roster  
> (one that suggest they have a presence subscription to me when they  
> do not, when I never approced this or revoked this) to still  
> receive my presence, without me knowing it or anyone being able to  
> detect that (without knowing I don't want this). That is completly  
> NOT an issue right now, and your proposal introduces this. Do you  
> understand that or not?

This discussion will now move to the how did the roster got  
"incorrect". External (evil) operation? Bug? Previous subscription  
attempt gone bad? Yes I understand that problem. But I think that  
rosters gone bad will only be an issue when evil is in play, and in  
that situation, you are already in trouble. As I mention in a  
previous email, if another person has access to the database to  
change his roster on the same server as your friend, most likely they  
will have access to the username and password of your friend also.

One small correction: it's not my proposal. I like it a lot, but it's  
not mine.

>> I think this proto-jep is something that would be negotiated  
>> between servers. If both servers agree to use it, then you  
>> activate it. If you don't want to use, don't advertise it.
> Yes, if you want.. fine. Like I said, I won't use it. Nor would I  
> recommend anyone else to use it. Nor would I ever endorse the idea  
> that a server that ONLY support your way can still be called XMPP  
> compliant. But if you want this, why not.. I could see it be useful  
> when you don't care about presence leaking (eg. if you have one of  
> those "presence thingies" on your blog anyway).
> That doesn't change the fact that your JEP opens up a security hole  
> and other problems, and the JEP should be honest about that. What  
> do you think the "Security Considerations" section is for?

Sorry. The security problem that you mention is already there. If a  
server is compromised (for me, access to his database is a  
compromise), there are a lot of ways I can get your presence. Maybe a  
forward rule even?

Security Considerations sections should not be about server  
compromise. In that situation, if the remote server is compromised,  
all privacy is lost, in this and on several other jeps.

Again, this is not a *new* problem with this proto-jep, IMHO...

>>> Yeah, what's the difference? Hack a server, install a recompiled  
>>> jabberd with spy mechanisms, and then make sure noone notices, or  
>>> make 1 little undetectable change to the database?
>> I'm sorry but both of these are very similar to me
> To make such a statement, either you don't care much about  
> security, or you don't know much or understand much about it.

well, I only hope my employer disagrees with you :).

An example: on the server we are currently using to host more than  
400k jabber users, a database compromise would allow you to install  
privacy lists on any user.

The assertion that you make that they are different things, a trojan- 
server or access to the database behind the server, might be true on  
some situations, if your server for example only uses the database  
for roster information. But if you also host the username and  
password of your users on the same database, then the person that  
access the database to insert my jid in his roster, might as well  
just pick up the username and password of my friend and get his  
presences this way.

There are a lot of setups out there.

Best regards,
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt

More information about the Standards mailing list