Dave Cridland wrote: > It's not that I normally lie in bed worrying about presence leaks,
Some folks on this list may not know what a presence leak is, so I define it thus (just changed this in rfc3920bis): A presence leak occurs when an entity's network availability is inadvertently and involuntarily revealed to a second entity that is not authorized to know the first entity's network availability. > but > as it happens, there's been much mention of presence leakage recently, > and I agree it's a fairly important issue. I can't say that I lose sleep over presence leaks. Do people really attach that much significance to presence information? > I'd like to open a discussion on this, because I'm pretty sure that I > don't know all the ways that presence can be leaked, and I'm not > convinced that we know good ways to avoid it, yet. > > I'd also like to focus on non-random resources. > > This is for two reasons. First, solving this case also solves the > random-resource-name case, especially important in those circumstances > where random turns out to be "utterly predictable".Second, even if you > do have a random resource, there are lots of cases whereby we disclose > it quite intentionally, such as joining a chatroom, or engaging in > transient conversation, etc. Such disclosure does not apply for the > entire session, or at least should not - we assume sessions to be > long-lived, in some cases very long lived. Yes that issue is covered by my use of "involuntarily" in the definition. Also, there are all sorts of social attacks by which you could discover my network availability -- asking mutual friends, tracking when I send emails even if I don't publish my XMPP presence, etc. Those are out of scope here. > So whilst I understand that random resource names are a form of defense > against presence leaks, I'd like to consider other methods of avoiding > these leaks. Good idea. We can't know whether random resources are even a good defense until we understand the attacks. > My goal would be a document that describes best practises for both > server and client developers to avoid disclosure of the existence of a > client connection without the user's intent. +1 I would use the phrase "network availability" instead of "client connection" (which might be thought to apply only to TCP connections, not BOSH for instance). > In as much as I can determine, presence leak happens when a stanza > generates different behaviour depending on whether the user is online or > not. There seem to be two broad divisions of presence leak. > > I see four cases: > > 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. I don't know how clients handle this now. > 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"). Right. So this is (potentially) a change in client behavior. > The alternative is that messages sent to offline users (or resources, > see below) do not emit errors at all. IOW changing server behavior is offline messages are not supported. > b) Attacker knows bare jid, and can discover a full jid that is online. > > I don't know any cases of this. Anyone else? Dictionary attack, I suppose. > c) Attacker knows full jid, and can determine if it is online. > > In principle, this is the simplest case. Aside from the above <message/> > attack - messages to offline full jids are processed just like those to > bare jids - there is also the <iq/> case - send an <iq/> and you will > receive either a result (user online), or an error, and by sending the > same <iq/> to the server, one might distinguish between online and offline. There are two possible branches here: 1. Does the attacker receive different responses (e.g., a completely different error condition)? 2. Can the attacker differentiate between the same response from the server and from the client (e.g., the client includes an old 'code' attribute but the server does not)? > 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 note that given that the initial request may or > may not be included, neither server or client should include it to avoid > distinction. (Since otherwise, if the server habitually includes the > original request, but the client does not, then the server is unlikely > to remember what it was). Agreed. > 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? > > I see this as being entirely possible, and in fact unavoidable, with > server-assigned resources. Otherwise I don't see that it helps - if I'm > always [EMAIL PROTECTED]/Home, then the attacker cannot tell if I've > been offline. I don't know whether we care about the past-presence attack. > So, am I missing any cases, or possible attacks? Other attacks come into play when a user has multiple accounts, but solutions to those attacks may require that we solve the many-body problem. :) Peter -- Peter Saint-Andre https://stpeter.im/
