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

Peter Saint-Andre stpeter at jabber.org
Tue May 29 22:12:18 UTC 2007

Rachel Blackman wrote:
> 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!

Well said, Rachel!

For those who are worried about the possibility of presence leaks 
occurring as you have described, we have a solution: toggle the "force 
the server to issue me a random resource" option in the client.

For those who are not worried, as you were.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070529/144e6810/attachment.bin>

More information about the Standards mailing list