On Monday 13 October 2008 07:42:01 Dave Cridland wrote:
> a) Attacker knows bare jid, and can determine that one or more full
> jids is online.
>
> I note that servers which don't implement offline messaging would
> typically bounce messages received when the user is offline with
> <service-unavailable/>, whereas no error would be forthcoming from an
> online, but silent, user.
>
> Mitigation for this might be that unless the user has sent presence
> (directed or otherwise) to the sender, the message should be bounced
> anyway. (It being a relatively simple situation to sort out between
> humans, who can simply say "No, it's okay, I got that").

I'd say presence doesn't matter for offline messages, but roster subscriptions 
do.  So, if someone I know sends me a message, then he gets no error and the 
message is queued offline (or if my server doesn't support offline messages 
then it is bounced).  If someone who I don't know sends me a message, then it 
could just always be bounced.

> c) Attacker knows full jid, and can determine if it is online.
[...]
> The solution to the <iq/> case would seem to be best handled by the
> client issuing an error, which is intercepted by its server and
> essentially rewritten.

I don't like this solution for a couple of reasons.

The main one is principle: why does my client have to field requests from 
contacts it doesn't care about?  That's unnecessary bandwidth, and seems 
totally ridiculous when I have a roster (whitelist) and policy engine at my 
server.

The others are technical: response times will be different between server and 
client, and canonicalizing error stanzas doesn't look that appealing.

Server-enforced privacy solves it all.

> d) Attacker knows full jid, knows that it is now online, and can
> detirmine that it has been online at a point in the past.
>
> Complicated point, so let's assume that you talk to someone, then -
> perhaps much later - enter a non-anonymous chatroom, which the
> attacker is also present in. The question is, can the attacker derive
> knowledge about whether you've been online the whole time?

If we give access rights to whoever has received a person's presence (which 
may indirectly include MUC participants), then I could see this being a 
problem.

What I'd suggest as a solution to this problem is to have two levels of 
privacy: 1) roster subscriptions, and 2) presence.  Contacts with 
subscriptions would have full access, but those with just presence (MUC 
rooms, or directed presence with someone not on your roster) would have more 
limited access.  For example, with limited access you could send messages and 
maybe retrieve the vcard, but you wouldn't be able to request iq:last (or 
something of that nature, revealing the past) unless you had a real 
subscription.

-Justin

Reply via email to