Justin, that all seems quite sensible!
Justin Karneges wrote: > 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
