Re: [Standards] Presence Leakage, and what we do about it.
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 >> , 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 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
Re: [Standards] XEP-0198
Pedro Melo wrote: > Hi, > > On Sep 30, 2008, at 1:04 PM, Dave Cridland wrote: >> On Tue Sep 30 00:27:49 2008, Justin Karneges wrote: >>> > I'm inclined to say, therefore, that either we redeclare the >>> > namespace on each XEP-0198 element, or else we just say that XEP-0198 >>> > extends the jabber:server and jabber:client namespaces - the latter >>> > is uglier in the specification, but much cleaner on the wire. >>> FWIW, dialback also uses a stream-level prefix, which would violate the >>> existing rule you speak of. >> No, because it's not an extension namespace, as per the definition. >> XEP-0198 doesn't fall foul of this rule as-is, either, the problem is >> that a naïve server (ie, one that's never heard of XEP-0198) cannot >> know whether or not the extension namespace rule has been violated, >> and from there, it cannot know if it should use a slower code path, or >> else it might choose to risk generating bad namespace prefixes. > > I might be missing something but such naive server, one that never heard > of XEP-0198, will not announce support for it, right? So what's the > problem? Right, as long as you never send stream management data unless you first learn that the other side supports the protocol, this seems fine. > I say that we should push the 0198 namespace to the , it > seems wasteful not to do it. It's a small thing really, but I suppose saving a few bytes per ack is a nice thing. > I've read the current draft and I like it, it seems very complete. I > think the text and examples of section 6, Stream Resumption, are a bit > strange. The examples after each paragraph don't match my expectations > based on the text, but I'll re-read the section more carefully to make > suggestions. I need to re-read it as well. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0198
Sorry, still catching up on email here. Dave Cridland wrote: > On Tue Sep 30 00:27:49 2008, Justin Karneges wrote: >> On Monday 29 September 2008 12:13:52 Dave Cridland wrote: >> > One reason is that we forbid the declaration of extension namespaces >> > (with a MUST NOT) at stream level. Now, as it happens, many >> > implementations cope with this fine, but in principle, they need not >> > - you could chop stanzas out and not rewrap them in the original >> > and be legal, for example. >> >> XEP-198 elements are not stanzas, and don't need to exist outside the >> context >> of the they are part of. >> >> > Quite true - hence my use of extension namespaces specifically, as > opposed to all namespaces. > > Non-extension namespaces - such as the TLS namespace we use - are > legally able to be declared at the stream level. It's a bit pointless, > perhaps, but it can be done that way according to the spec. > > >> If XMPP-Core forbids declaring namespace prefixes in , then >> IMO this >> restriction should be relaxed in the bis draft. >> >> > It doesn't - it forbids declaring extension namespaces - ie, those used > within stanzas. > > >> I understand that declaring a namespace prefix in and then >> using it >> in a stanza could result in some routability problems, but I think >> this is >> only an issue for naive implementations? >> >> > No, declaring an extension namespace in a stream would indeed cause > non-namespace-well-formed data to be emitted from a very naïve, but > legal, server. However, even in the release we're about to make, where I > fixed this issue, it still causes us to slow down, since we have to > fully parse and reconstruct every stanza, which is considerably slower. > > >> > I'm inclined to say, therefore, that either we redeclare the >> > namespace on each XEP-0198 element, or else we just say that XEP-0198 >> > extends the jabber:server and jabber:client namespaces - the latter >> > is uglier in the specification, but much cleaner on the wire. >> >> FWIW, dialback also uses a stream-level prefix, which would violate the >> existing rule you speak of. >> >> > No, because it's not an extension namespace, as per the definition. > XEP-0198 doesn't fall foul of this rule as-is, either, the problem is > that a naïve server (ie, one that's never heard of XEP-0198) cannot know > whether or not the extension namespace rule has been violated, and from > there, it cannot know if it should use a slower code path, or else it > might choose to risk generating bad namespace prefixes. > > I've an idea, though. We could define "stream namespaces" to mean those > namespaces which are not extension namespaces as defined - namespaces > which are never used within stanzas, but only within stream elements. > > From there, it's easy to reserve a chunk of URN-space for them, so - and > I appreciate PSA will now wish to throttle me - we'd change the > namespace of XEP-0198 again, to something like: > > urn:xmpp:stream:sm:0 > > And then servers can now that, since the namespace begins > "urn:xmpp:stream:", it's safe to ignore if they don't understand it. So anything starting with urn:xmpp:stream: would be handled in this special way? I don't know whether I like that, since there are exceptions for older namespaces etc. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
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 > , 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 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
Re: [Standards] "rich presence" updates
Stephan Maka wrote: > Peter Saint-Andre wrote: >> I recently updated all of the PEP-based extensions for "rich presence" >> payloads: >> >> XEP-0080 User Geolocation >> XEP-0084 User Avatar >> XEP-0107 User Mood >> XEP-0108 User Activity >> XEP-0194 User Chatting >> XEP-0195 User Browsing >> XEP-0196 User Gaming >> XEP-0197 User Viewing > > Quite a number, how about listing them under PEP on the PubSub tech > page? Done. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Jonathan Schleifer wrote: > Am 13.10.2008 um 22:45 schrieb Peter Saint-Andre: > >> 2. Have developers experienced any problems with the protocol as defined >> in XEP-0085? If so, please describe the problems and, if possible, >> suggested solutions. > > Yes, the behaviour of sending it at the first message and only replying > with it when we received a message with it often leads to a problem with > offline messages. When one receives an offline message without it and > the user answers, the client will answer without the. Both users are > online at that time. Now due to the offline message, they BOTH think the > other end doesn't support XEP-85 and chat state notifications are never > used. I already triggered that several times in Gajim. Aha, I've never seen that. > Solution: Caps, it's already in the XEP. But sadly, no client determines > support via caps. Plus the "try & error method" must be used for > compatibility reasons. > > Encouraging the use of caps in it would be nice, maybe even mark the try > & error method as deprecated. I'd be fine with that. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Dave Cridland wrote: > On Mon Oct 13 15:42:01 2008, Dave Cridland wrote: >> So, am I missing any cases, or possible attacks? > > Of course, there's also that bit in Star Wars where Darth Vader says, "I > have felt your presence", but I can't think of a useful mitigation > against use of The Force by The Sith, and besides, it probably only > affects you if you happen to be a Jedi Knight yourself. Nope, I'm a saint, not a knight. :)
Re: [Standards] Presence Leakage, and what we do about it.
On Mon Oct 13 15:42:01 2008, Dave Cridland wrote: So, am I missing any cases, or possible attacks? Of course, there's also that bit in Star Wars where Darth Vader says, "I have felt your presence", but I can't think of a useful mitigation against use of The Force by The Sith, and besides, it probably only affects you if you happen to be a Jedi Knight yourself. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] well-formedness
OK here's what I have now in my working copy of rfc3920bis: *** 12.3. Well-Formedness There are two varieties of well-formedness: o "XML-well-formedness" in accordance with the definition of "well- formed" in Section 2.1 of [XML]. o "Namespace-well-formedness" in accordance with the definition of "namespace-well-formed" in Section 7 of [XML-NAMES]. The following rules apply. An XMPP entity MUST NOT generate data that is not XML-well-formed. An XMPP entity MUST NOT accept data that is not XML-well-formed; instead it MUST return an stream error and close the stream over which the data was received. An XMPP entity MUST NOT generate data that is not namespace-well- formed. An XMPP server SHOULD NOT route or deliver data that is not namespace-well-formed, but MUST NOT return a stream error in response to the receipt of such data. Note: Because these restrictions were underspecified in an earlier revision of this specification, it is possible that implementations based on that revision will send data that does not comply with the restrictions; an entity SHOULD be liberal in accepting such data. ***
Re: [Standards] Presence Leakage, and what we do about it.
On Mon Oct 13 22:54:45 2008, Jonathan Schleifer wrote: Am 13.10.2008 um 23:44 schrieb Peter Saint-Andre: Right, even *I* stopped saying "email delenda est" a few years ago. :) But there's no reason for it if clients would implement XEP-0198 and handle messages with type='normal' like e-mail. One legacy protocol less needed then :). Yes, because sending large binary attachments would be so much easier then. And think of the joy of how this would interface with the massive deployment of perfectly functioning SMTP servers. It'd be so easy to say "Look, throw away your binary-capable fault-tolerant network, and replace it with our non-equivalent XML-based system, and will choke if a server is unavailable for more than a minute!". I can see people rushing to our doors now. And they're wearing such nice white coats. They seem to be shouting something about "medication". Hmmm. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Presence Leakage, and what we do about it.
Am 13.10.2008 um 23:44 schrieb Peter Saint-Andre: Right, even *I* stopped saying "email delenda est" a few years ago. :) But there's no reason for it if clients would implement XEP-0198 and handle messages with type='normal' like e-mail. One legacy protocol less needed then :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] multiple FORM_TYPEs
Pavel Simerda wrote: > On Wed, 08 Oct 2008 22:28:36 -0600 > Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > >> Brett Zamir wrote: >>> I had been wondering whether multiple FORM_TYPEs in Data Forms be >>> added to allow for multiple /standard/ specs being represented at >>> the same time... >>> >>> I have no particular need for this now, but I was curious about it >>> for the sake of future extensibility... >>> >>> Jack, in the developer chat room today mentioned Pubsub Queueing at >>> http://xmpp.org/extensions/inbox/pubsub-queueing.html (in example >>> 1) as having such a need, but I thought I'd bring it up again here >>> to bring it up formally... >> Thinking ahead, eh? >> >> Scoping the same data form with two different FORM_TYPEs would be like >> qualifying the same XML element with different namespaces. No go. Or >> at least that's how XEP-0004 and XEP-0068 were designed. >> >> But you could include two different forms... >> >> Peter >> > > Can I extend this question? > > Shouldn't we use some sort of more proper namespacing of form fields > (or multiple forms) instead of practice that like node config in PubSub, > etc? Yes, we could do that within the current XEP-0004 framework if we want to (basically say XEP-0068 was stupid and here's a better approach). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Dave Cridland wrote: > On Mon Oct 13 22:31:33 2008, Jonathan Schleifer wrote: >> Am 13.10.2008 um 23:30 schrieb Dave Cridland: >> >>> Actually, offline messages is something that really annoys me. Can't >>> stand them. If I'm not online, use email, far more reliable. >>> >>> I appreciate that is but a personal opinion. >> >> >> IMO, it would be nice if you could retrieve them manually and your >> client just shows your "XXX new offline messages", so XMPP can >> finally replace e-mail :). > > But I'm quite happy with email, thanks. Right, even *I* stopped saying "email delenda est" a few years ago. :) /psa
Re: [Standards] Presence Leakage, and what we do about it.
On Mon Oct 13 22:31:33 2008, Jonathan Schleifer wrote: Am 13.10.2008 um 23:30 schrieb Dave Cridland: Actually, offline messages is something that really annoys me. Can't stand them. If I'm not online, use email, far more reliable. I appreciate that is but a personal opinion. IMO, it would be nice if you could retrieve them manually and your client just shows your "XXX new offline messages", so XMPP can finally replace e-mail :). But I'm quite happy with email, thanks. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] ,
Ralph Meijer wrote: > On Fri, Oct 10, 2008 at 05:30:26AM +0800, Brett Zamir wrote: >> [..] >> >> Since having a @type on is recommended and as the other types don't >> seem to apply, should Pubsub recommend use of for all >> of its messages? > > As I mentioned in another thread the other day, the publish-subscribe > specification does not require RFC 3921, because a large part of it > should also work in non-IM contexts. Hence, those message types might > not apply and using no message type is the best we can do. Well, if you receive a message with a type you don't understand, you MUST treat it as type='normal', so I think it would be OK to talk about type='headline' in XEP-0060 and certainly XEP-0163 (which does depend on RFC 3921). Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] account preferences
Dave Cridland wrote: > Actually, offline messages is something that really annoys me. Can't > stand them. If I'm not online, use email, far more reliable. > > I appreciate that is but a personal opinion. So I take it you'd like an "account preferences" technology that enables you to disable offline messages? Other prefs of interest: - store offline messages, except if the message is of type headline - deliver to all resources any message that's addressed to the bare JID (à la Google Talk), perhaps with the ability to opt out for any given resource I'm sure there are others... /psa
Re: [Standards] Presence Leakage, and what we do about it.
On Mon Oct 13 22:22:02 2008, Andrew Plotkin wrote: On Mon, 13 Oct 2008, Peter Saint-Andre wrote: c) Attacker knows full jid, and can determine if it is online. In principle, this is the simplest case. Aside from the above attack - messages to offline full jids are processed just like those to bare jids - there is also the case - send an and you will receive either a result (user online), or an error, and by sending the same 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)? Or the round-trip time for a server-generated error is shorter than that for a client-generated error. (Or a client error rewritten by the server.) Timing attacks are tricky in many cases, unless you happen to be on the same server. Between timing attacks and low-level formatting details (whitespace, order of attributes), getting a server to imitate a client is a scary minefield. Ah, no, I'm not suggesting that, I'm suggesting that servers intercept client errors and coerce them into the form, at least mitigating branch 2. If a client is giving an entirely different error, the client is at fault, or else is (apparently) intentionally revealing presence. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Presence Leakage, and what we do about it.
Am 13.10.2008 um 23:30 schrieb Dave Cridland: Actually, offline messages is something that really annoys me. Can't stand them. If I'm not online, use email, far more reliable. I appreciate that is but a personal opinion. IMO, it would be nice if you could retrieve them manually and your client just shows your "XXX new offline messages", so XMPP can finally replace e-mail :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Presence Leakage, and what we do about it.
On Mon Oct 13 21:11:55 2008, Jonathan Schleifer wrote: Am 13.10.2008 um 22:01 schrieb Peter Saint-Andre: IOW changing server behavior is offline messages are not supported. No, it's only a problem when the server does *NOT* support supported, as it returns an error then. I'd say we make offline messages mandatory, IMO, offline messages is something that no implementation should be allowed to leave out. */me looks at gtalk* Actually, offline messages is something that really annoys me. Can't stand them. If I'm not online, use email, far more reliable. I appreciate that is but a personal opinion. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Presence Leakage, and what we do about it.
Andrew Plotkin wrote: > On Mon, 13 Oct 2008, Peter Saint-Andre wrote: > >>> c) Attacker knows full jid, and can determine if it is online. >>> >>> In principle, this is the simplest case. Aside from the above >>> attack - messages to offline full jids are processed just like those to >>> bare jids - there is also the case - send an and you will >>> receive either a result (user online), or an error, and by sending the >>> same 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)? > > Or the round-trip time for a server-generated error is shorter than that > for a client-generated error. (Or a client error rewritten by the server.) > > Between timing attacks and low-level formatting details (whitespace, > order of attributes), getting a server to imitate a client is a scary > minefield. Agreed. I don't know that I think the timing attack is all that likely (given normal network latency etc.), but I do agree that jumping through these hoops for the rather picayune purpose of preventing presence leaks is overkill. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
On Mon, 13 Oct 2008, Peter Saint-Andre wrote: c) Attacker knows full jid, and can determine if it is online. In principle, this is the simplest case. Aside from the above attack - messages to offline full jids are processed just like those to bare jids - there is also the case - send an and you will receive either a result (user online), or an error, and by sending the same 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)? Or the round-trip time for a server-generated error is shorter than that for a client-generated error. (Or a client error rewritten by the server.) Between timing attacks and low-level formatting details (whitespace, order of attributes), getting a server to imitate a client is a scary minefield. --Z -- "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." * Don't you think McCain looks tired?
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 13.10.2008 um 22:45 schrieb Peter Saint-Andre: 2. Have developers experienced any problems with the protocol as defined in XEP-0085? If so, please describe the problems and, if possible, suggested solutions. Yes, the behaviour of sending it at the first message and only replying with it when we received a message with it often leads to a problem with offline messages. When one receives an offline message without it and the user answers, the client will answer without the. Both users are online at that time. Now due to the offline message, they BOTH think the other end doesn't support XEP-85 and chat state notifications are never used. I already triggered that several times in Gajim. Solution: Caps, it's already in the XEP. But sadly, no client determines support via caps. Plus the "try & error method" must be used for compatibility reasons. Encouraging the use of caps in it would be nice, maybe even mark the try & error method as deprecated. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Presence Leakage, and what we do about it.
Am 13.10.2008 um 22:14 schrieb Peter Saint-Andre: I think Dave was suggesting that servers would stop returning the error. But perhaps I misunderstood. That's a bad idea, the user will never know that the message wasn't stored for later retrieval. IMO, making offline message storage mandatory is the way to go. Or to also return if you're invisible / the other side got no subscription until you answer to a message. -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] Call for Experience: XEP-0085 (Chat State Notifications)
In its meeting last week, the XMPP Council agreed to issue a "Call for Experience" regarding XEP-0085: Chat State Notifications, in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. Who has implemented XEP-0085? Please note that the protocol must implemented in at least two separate codebases. 2. Have developers experienced any problems with the protocol as defined in XEP-0085? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0085 clear and unambiguous? Are more examples necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments on this XEP, please provide them by the close of business on Friday, October 31, 2008. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the XEP here: http://www.xmpp.org/extensions/xep-0085.html Please send all feedback to the list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] Call for Experience: XEP-0012
The XMPP Council would like to advance more of the XSF's standards track specifications from Draft to Final. Background information can be found here: http://xmpp.org/extensions/xep-0001.html#approval-std http://xmpp.org/extensions/xep-0001.html#states-Draft http://xmpp.org/extensions/xep-0001.html#states-Final In its meeting last week, the Council agreed to issue a "Call for Experience" regarding XEP-0012: Last Activity. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. Who has implemented XEP-0012? Please note that the protocol must implemented in at least two separate codebases. 2. Have developers experienced any problems with the protocol as defined in XEP-0012? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0012 clear and unambiguous? Are more examples necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments on this XEP, please provide them by the close of business on Friday, October 31, 2008. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the XEP here: http://www.xmpp.org/extensions/xep-0012.html Please send all feedback to the list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Jonathan Schleifer wrote: > Am 13.10.2008 um 22:01 schrieb Peter Saint-Andre: > >> IOW changing server behavior is offline messages are not supported. s/is/if/ > > No, it's only a problem when the server does *NOT* support supported, as > it returns an error then. I'd say we make offline messages mandatory, > IMO, offline messages is something that no implementation should be > allowed to leave out. */me looks at gtalk* I think Dave was suggesting that servers would stop returning the error. But perhaps I misunderstood. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Am 13.10.2008 um 22:01 schrieb Peter Saint-Andre: IOW changing server behavior is offline messages are not supported. No, it's only a problem when the server does *NOT* support supported, as it returns an error then. I'd say we make offline messages mandatory, IMO, offline messages is something that no implementation should be allowed to leave out. */me looks at gtalk* -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] jabber:iq:auth to Obsolete?
In its meeting last week, the XMPP Council discussed the issue of potentially changing the status of XEP-0078 (Non-SASL Authentication) from Deprecated to Obsolete. The Council had consensus to make this change, but as XEP Editor (no longer Council Chair, ha!) I'd like gauge the consensus of the list regarding this change. Naturally, a server, client, or library could continue to support the jabber:iq:auth protocol even if the XEP that documents it is Obsolete, and deployed services could still offer the feature (after all, there are plenty of obsolete clients in the world and a server might want to enable those clients to connect). However, my sense is that this change would indicate that the XSF thinks it is no longer appropriate for new software to include support for jabber:iq:auth, and instead to support only SASL authentication. Here are some relevant links: http://xmpp.org/extensions/xep-0078.html http://xmpp.org/extensions/xep-0001.html#states-Deprecated http://xmpp.org/extensions/xep-0001.html#states-Obsolete If you have concerns about this change, please speak up. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
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 > , 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 > attack - messages to offline full jids are processed just like those to > bare jids - there is also the case - send an and you will > receive either a result (user online), or an error, and by sending the > same 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 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 t
Re: [Standards] Presence Leakage, and what we do about it.
Jonathan Schleifer wrote: > Am 13.10.2008 um 20:11 schrieb Peter Saint-Andre: > >> Just because [EMAIL PROTECTED] has a contact at shakespeare.lit doesn't >> mean he can see the presence of everyone at shakespeare.lit. > > > He can't, but tybalt.lit (not [EMAIL PROTECTED]) can send IQ queries > then which are happily answered. At least, IIRC, that's possible with > some implementations. But Romeo doesn't have anyone from tybalt.lit in his roster, so I am suggesting that Romeo's client must ignore any disco#info requests from tybalt.lit. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Am 13.10.2008 um 20:11 schrieb Peter Saint-Andre: Just because [EMAIL PROTECTED] has a contact at shakespeare.lit doesn't mean he can see the presence of everyone at shakespeare.lit. He can't, but tybalt.lit (not [EMAIL PROTECTED]) can send IQ queries then which are happily answered. At least, IIRC, that's possible with some implementations. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Presence Leakage, and what we do about it.
Jonathan Schleifer wrote: > Am 13.10.2008 um 19:35 schrieb Peter Saint-Andre: > >> Sure. So choose your friends carefully. > > No, I mean, you are [EMAIL PROTECTED], now let's say Tybalt (IIRC > he's of the Capulets, no? Thus an 'attacker') registers > [EMAIL PROTECTED] Tybalt also has his own server called tybalt.lit > and now adds [EMAIL PROTECTED] in [EMAIL PROTECTED] Now he can get > Romeos presence (or whereabouts in this case, so he knows where to find > him when he wants to kill him :)). How? Just because [EMAIL PROTECTED] has a contact at shakespeare.lit doesn't mean he can see the presence of everyone at shakespeare.lit. Have you read RFC 3921 yet? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Am 13.10.2008 um 19:35 schrieb Peter Saint-Andre: Sure. So choose your friends carefully. No, I mean, you are [EMAIL PROTECTED], now let's say Tybalt (IIRC he's of the Capulets, no? Thus an 'attacker') registers [EMAIL PROTECTED] . Tybalt also has his own server called tybalt.lit and now adds [EMAIL PROTECTED] in [EMAIL PROTECTED] Now he can get Romeos presence (or whereabouts in this case, so he knows where to find him when he wants to kill him :)). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Jabber Search var issue
Brett Zamir wrote: > Hi, > > In http://xmpp.org/extensions/xep-0055.html , example 8, we believe @var > should be 'x-gender' and not 'gender' per Field Standardization... Thanks for the bug report. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Jonathan Schleifer wrote: > Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > >> So start writing. :P > > It was asked for possible solutions for that. I just named a few :). > >> Hmm. Mostly I see that as the server's problem -- it can collect that >> information from its own users. If it comes across a hash that it >> can't gather locally, then you're right that it needs to figure out >> the supported features by pinging a user at "server2", presumably >> based on whether the user has a contact at server1. But the user's >> client needs to be careful about replying to such requests -- if it >> comes from the server associated with a contact, then there's no real >> problem (because the contact's server already has access to the >> user's presence traffic anyway). But if the disco#info request comes >> from a server that is totally unknown to the user's client because >> the user has no contacts at that domain (e.g., "attacker.com"), then >> the user's client needs to return a service-unavailable error. IMHO >> this is clear from XEP-0030, but we can add some text about it to >> XEP-0115 if people think that would help. > > An attacker could still create an account on the server and then add > [EMAIL PROTECTED], thus it would seem legitimate. Sure. So choose your friends carefully. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > So start writing. :P It was asked for possible solutions for that. I just named a few :). > Hmm. Mostly I see that as the server's problem -- it can collect that > information from its own users. If it comes across a hash that it > can't gather locally, then you're right that it needs to figure out > the supported features by pinging a user at "server2", presumably > based on whether the user has a contact at server1. But the user's > client needs to be careful about replying to such requests -- if it > comes from the server associated with a contact, then there's no real > problem (because the contact's server already has access to the > user's presence traffic anyway). But if the disco#info request comes > from a server that is totally unknown to the user's client because > the user has no contacts at that domain (e.g., "attacker.com"), then > the user's client needs to return a service-unavailable error. IMHO > this is clear from XEP-0030, but we can add some text about it to > XEP-0115 if people think that would help. An attacker could still create an account on the server and then add [EMAIL PROTECTED], thus it would seem legitimate. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Presence Leakage, and what we do about it.
Jonathan Schleifer wrote: > Am 13.10.2008 um 19:03 schrieb Peter Saint-Andre: > >> So file bug reports with those client teams. The same goes for the other >> points you bring up. > > That's not entirely solvable by bug reports. That suggestion for iq > needs a new XEP for example. So start writing. :P > That thing with is also not easy to fix, as > server rely on that for caching caps. Wildfire for example relies on that. Hmm. Mostly I see that as the server's problem -- it can collect that information from its own users. If it comes across a hash that it can't gather locally, then you're right that it needs to figure out the supported features by pinging a user at "server2", presumably based on whether the user has a contact at server1. But the user's client needs to be careful about replying to such requests -- if it comes from the server associated with a contact, then there's no real problem (because the contact's server already has access to the user's presence traffic anyway). But if the disco#info request comes from a server that is totally unknown to the user's client because the user has no contacts at that domain (e.g., "attacker.com"), then the user's client needs to return a service-unavailable error. IMHO this is clear from XEP-0030, but we can add some text about it to XEP-0115 if people think that would help. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Am 13.10.2008 um 19:03 schrieb Peter Saint-Andre: So file bug reports with those client teams. The same goes for the other points you bring up. That's not entirely solvable by bug reports. That suggestion for iq needs a new XEP for example. That thing with is also not easy to fix, as server rely on that for caching caps. Wildfire for example relies on that. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Presence Leakage, and what we do about it.
Jonathan Schleifer wrote: > For c.): > > It seems that every client happily answers to IQ requests when they are > sent from a JID only containing a host, e.g. type='get'> will always be answered. So file bug reports with those client teams. The same goes for the other points you bring up. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Presence Leakage, and what we do about it.
Michal 'vorner' Vaner <[EMAIL PROTECTED]> wrote: > I'm against that. If I have a bot that just do not care about presence > and I want it as uploader to my website (I send it a file, it stores > it on the server), it stops working. We could have that as a XEP that needs to be enabled by the client. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Presence Leakage, and what we do about it.
Hello On Mon, Oct 13, 2008 at 05:08:01PM +0200, Jonathan Schleifer wrote: > As you already said, IQ requests are a problem in general. That's why I > think that the *SERVER* should reply with an error if there's no > subscription or a privacy list blocking presence-out. I'm against that. If I have a bot that just do not care about presence and I want it as uploader to my website (I send it a file, it stores it on the server), it stops working. This should be at last configurable (feature turned on on request only). With regards -- Have you ever be told you are an airplane? Michal 'vorner' Vaner pgptwpOX9fPTW.pgp Description: PGP signature
Re: [Standards] Presence Leakage, and what we do about it.
For c.): It seems that every client happily answers to IQ requests when they are sent from a JID only containing a host, e.g. from='attacker.com' type='get'> will always be answered. As you already said, IQ requests are a problem in general. That's why I think that the *SERVER* should reply with an error if there's no subscription or a privacy list blocking presence-out. What's also very easy: Send a message with XEP-0184 attached, if you get a reply, the user is only. This even reveals the resource. In Gajim, we have some basic checks to prevent that. They are subscription-based, but currently ignore privacy lists. Now as one of the goals of XMPP is to have simple clients, I'd suggest a way for the client to determine if there's a privacy list that would block presence-out to that user, so you have something like: foo! Sure, only-route-if-presence-out-allowed could be shorted, but I chose that name here to make clear what it does. -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] Presence Leakage, and what we do about it.
It's not that I normally lie in bed worrying about presence leaks, but as it happens, there's been much mention of presence leakage recently, and I agree it's a fairly important issue. Aside from anything else, if presence leaks badly enough, it can leave a nasty stain on the carpet. 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. 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. 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. 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 , 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"). The alternative is that messages sent to offline users (or resources, see below) do not emit errors at all. b) Attacker knows bare jid, and can discover a full jid that is online. I don't know any cases of this. Anyone else? c) Attacker knows full jid, and can determine if it is online. In principle, this is the simplest case. Aside from the above attack - messages to offline full jids are processed just like those to bare jids - there is also the case - send an and you will receive either a result (user online), or an error, and by sending the same to the server, one might distinguish between online and offline. The solution to the 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). 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. So, am I missing any cases, or possible attacks? Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] iq query caching
Pedro Melo wrote: > Hi, > > On Oct 13, 2008, at 10:08 AM, Eric Cestari wrote: > >> Hi, >> >> Working on disco and result set management, I am wondering why there >> is no cache management tools in XMPP. >> Why not implement Etags, If-none-match and If-modified-since XMPP >> versions ? > > for rosters see: http://xmpp.org/extensions/inbox/roster-versioning.html In fact that was published as XEP-0237 and I recently generalized it beyond rosters. http://xmpp.org/extensions/xep-0237.html Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] iq query caching
Hi, On Oct 13, 2008, at 10:08 AM, Eric Cestari wrote: Hi, Working on disco and result set management, I am wondering why there is no cache management tools in XMPP. Why not implement Etags, If-none-match and If-modified-since XMPP versions ? for rosters see: http://xmpp.org/extensions/inbox/roster-versioning.html Best regards, Stanzas can get very large in some disco cases, and traffic could be greatly reduced, at a low cost of implementation. Query : -- 1223888705 Response : While writing the previous example, stpeter's famously large roster also came to my mind. Implementing such a system could greatly reduce the load when the user connect on both the server and the client. I did a quick googling on XMPP cache managment. Nothing related came up. Was there any previous talks about it ? Eric Cestari -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] iq query caching
Eric Cestari wrote: Thanks Maciek. And a great useless first post on this mailing list for me :) It's not useless - maybe you just resurrected this old idea :) And maybe this time is a good time. We'll see. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] iq query caching
Thanks Maciek. And a great useless first post on this mailing list for me :) Anyway, 3 years later, is there still no interest in it ? I understand that, given the push aspect of XMPP, caching is not as necessary as it is with HTTP, but I sure could use it. Eric Le 13 oct. 08 à 11:49, Maciek Niedzielski a écrit : Eric Cestari wrote: Working on disco and result set management, I am wondering why there is no cache management tools in XMPP. Why not implement Etags, If-none-match and If-modified-since XMPP versions ? http://xmpp.org/extensions/xep-0150.html I think there was not enough interest that time to push it further. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] iq query caching
Eric Cestari wrote: Working on disco and result set management, I am wondering why there is no cache management tools in XMPP. Why not implement Etags, If-none-match and If-modified-since XMPP versions ? http://xmpp.org/extensions/xep-0150.html I think there was not enough interest that time to push it further. -- Maciek xmpp:[EMAIL PROTECTED]
[Standards] iq query caching
Hi, Working on disco and result set management, I am wondering why there is no cache management tools in XMPP. Why not implement Etags, If-none-match and If-modified-since XMPP versions ? Stanzas can get very large in some disco cases, and traffic could be greatly reduced, at a low cost of implementation. Query : -- 1223888705 Response : While writing the previous example, stpeter's famously large roster also came to my mind. Implementing such a system could greatly reduce the load when the user connect on both the server and the client. I did a quick googling on XMPP cache managment. Nothing related came up. Was there any previous talks about it ? Eric Cestari
