[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]
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
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...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards