[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]

Rachel Blackman rcb at ceruleanstudios.com
Tue May 29 22:04:49 UTC 2007

On May 29, 2007, at 1:39 PM, Dave Cridland wrote:

>>> The resource is opaque, but technically so is the whole JID.  I  
>>> don't see the problem with making any part of it look nice.
>> My bare jid is my 'address' in xmpp and so not opaque.
> No, sorry, it's still opaque. The user portion of your bare jid  
> does not mean anything outside the context of your bare jid, and  
> means little to anyone outside your domain except as an opaque  
> string. For some reason, though, we're all happy to have usernames  
> that are human readable, and moreover human identifiable. Perhaps  
> we should make all those be hex digits - it might save us from  
> identity theft, so there's a solid, security-based reasoning here.

C'mon, be serious, folks.  (And this is nothing personal, Dave, but  
you just happened to be the post I'm replying to here.)

My JID (or XID, or XMPP End-Point Identifier or whatever the current  
Politically Correct term is) is far more important than a resource.   
Let's get away from that argument; I'm not going to hand out  
'sparks at jabber.org/Trillian' or 'sparks at jabber.org/Mobile' or  
'sparks at jabber.org/Adium' as my JID to folks; I'm going to just give  
them 'sparks at jabber.org' and be done with it.

The argument here is not that 'randomly generating strings for each  
session is good, so we should do more of it.'  The argument here is  
that a number of people have expressed concern that XMPP is presently  
vulnerable to 'presence leaking.'

Specifically, the argument is that the ability to guess fully- 
qualified JIDs and probe them will allow you to determine if the  
person is online on that resource or not.  Most of us (as has been  
noted) do things like 'Office' and 'Home' and 'Mobile' for our  
resources.  Or just use the client default resources (Trillian,  
Adium, etc.).  By sending various IQ packets to 'common' resources  
off a target JID, I can watch for the difference between the server's  
error response and a real response (or even a /different/ error  
response) from the client, and thus determine that the resource is,  
indeed, online and has a client answering rather than the server.

I don't know that I agree that this is a significant security issue,  
but I /do/ agree that if you accept the premise that it /is/, the  
human-readable and meaningful resources are a liability.  The RFCs  
provide for randomly-generated resources, and we have -- or can  
define -- XEPs to attach actual meaning to those resources.  So it's  
a fairly simple solution (compared to, say, forcing every server to  
rewrite the error messages from clients to match their own ordering  
of tags, specific responses, and so on).

If you disagree that this is a problem and think this is being  
regarded as standards at xmpp.org/mountain when we're actually on  
standards at xmpp.org/molehill, that's great.

If you agree it's a problem and have an alternate solution, that's  
great too!

But this conversation as a whole is sort of reaching a point where  
we're trying to build up or discredit the argument by tangential (and  
occasionally wildly stretching) analogies, rather than actually  
addressing what the original concern was. :)

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/

More information about the Standards mailing list