[Standards] invisibility (was: Re: xep-0199 redundancy)

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 27 16:28:27 UTC 2007


Jonathan Dickinson wrote:
> You have hit a rather nasty nail on the head. I can think of a whole
> bunch of protocols that could be used to 'leak' presence. 

We had a long long discussion thread about this a few months ago, as a
result of which we modified rfc3920bis to recommend the use of random
resource identifiers that are generated by the server, not the client.
See here for the results:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-03.html#bind

Feel free to go through the mailing list archives if you want to read
the entire discussion.

> Even having
> people know that you are on-line on any resource is unacceptable.

Um, it's called the Extensible Message *and Presence* Protocol. If you
have a problem with presence, you don't have to support that part of the
protocol and you could just use pure messaging. Or SMS. Or email. :)

> I think we may need just a bit of restructuring here. Along the lines of
> the following scenario:
> 
> * Romeo goes invisible, Capulet sentry are about ;).

First of all, invisible is not supported in the core protocols. So if
you are going to use invisible mode, you do so at your own risk. It is a
known issue that invisible is not *really* invisible. IMHO the whole
concept of invisibility is idiotic, but that's just me.

Speaking of which, there are three approaches to invisibility:

http://www.xmpp.org/extensions/xep-0018.html

http://www.xmpp.org/extensions/xep-0126.html

http://www.xmpp.org/extensions/xep-0186.html

IMHO it would be best to standardize on XEP-0186. But read all three and
let us know what you think.

> * Juliet sends Romeo a batch of IQ stanzas. 

See above on random, server-generated resource identifiers. When Romeo
"goes invisible", his server sends <presence type='unavailable'/>. So as
far as Juliet knows, Romeo is now offline. Why is she sending IQs to a
full JID that is offline? Because she is guessing that maybe he still is
online?

> His client can either ask
> him if he trusts that person, or each stanza. Or it could cache the
> response stanza and not interact with Romeo at all.

See the Security Considerations in XEP-0186.

> * Romeo sends Juliet a stanza of any type.
> * His client realises that he is open to communication with her. It
> sends the cached response stanzas, and responds immediately to every
> stanza henceforth.

Probably, yes.

> * A evil villain sends Romeo a message with a delivery notification so
> that he can check if he is on-line (and triangulate his position using
> genius methods).

How does the evil villain know Romeo's full JID? Because it guessed?
(That's harder if random, server-generated resource identifiers.) Did it
read the traffic off the wire? (Use channel encryption!) Is it the
server admin for capulet.lit or montague.lit? (Use a trusted server!)

> * Romeo receives the message, but the villain isn't on his temporary
> white-list, so his client does not report that it received the message.
> * The villain tries again with a ping IQ stanza.
> * Once again, Romeo's client doesn't respond.
> * Romeo leaves the garden and goes not-invisible.
> * His client informs him that there are now outstanding responses.

Maybe. I'm not convinced that the client needs to cache all those requests.

> * He chooses to send them now that he is clear of danger.
> 
> What do you all think? I think the ways to assign a person to the
> temporary white-list would be to assign them to it specifically (e.g. a
> context menu), or by sending any stanza (once you have sent them a
> stanza they can pretty much figure out that you are on-line).

This sounds like an implementation note for XEP-0186. But I do not think
that this a general worry about presence leaks in "a whole bunch of
protocols".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

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


More information about the Standards mailing list