-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oops, posted to the wrong list. :)
- -------- Original Message -------- Subject: Re: [Standards] PubSub Security considerations Date: Mon, 14 Sep 2009 16:47:23 -0600 From: Peter Saint-Andre <[email protected]> Reply-To: XMPP Standards <[email protected]> To: XMPP Standards <[email protected]> References: <[email protected]> <[email protected]> <1244794546.4288.26.ca...@dwaal> On 6/12/09 2:15 AM, Ralph Meijer wrote: > On Thu, 2009-06-11 at 19:20 -0400, Brian Cully wrote: >> On Jun 11, 2009, at 11:31, Nicolas Vérité <[email protected] >> et> wrote: >> >>> Dear all, >>> >>> In the "Security considerations" section of the PubSub spec, shouldn't >>> we warn of the possible presence leaks, since subscribers (possibly >>> not in the user's roster) are instantly notified of a user's >>> publication? >> Agreed. This is a subtle condition and should probably be called out. > > I think it is a lot more subtle than summarized here. > > First off, the basic model of XEP-0060 is that there are nodes at some > service and items get published to it by publishers. Subscribers to > nodes get notifications on every publish, and the notifications do not > expose which entity published that item. Basically, this means that a > notification does not definitively expose an entity's availability, and > not even their existence. > > Going further, notifications do not even imply explicit publish actions, > but items could merely start to exist from within a system or by some > out-of-band protocol, and cause a notification to be sent out. > > Second, XEP-0060 does not depend on XMPP IM, so entities do not > necessarily represent people. > > Third, we explicitly started developing a publish-subscribe protocol > because we consider information like the music somebody is playing on > their desktop, or an entity's location are orthogonal to availability. > > Fourth, nodes themselves are not necessarily tied to a particular > entity. In Personal Eventing (XEP-0163), of course, this is a bit > different, because nodes are then tied to a entity's (person's?) user > account. So here the existence of a user is exposed. I suppose this is a > moot point because to discover such nodes, the existence of that user > would already need to be exposed via some other means. > > But even then, a notification does not necessarily expose an entity's > availability. The actual publisher could still be another entity (e.g. > FireEagle publishing a location to your own XEP-0080 node). > > And finally, whether a particular notification exposes someone's > availability highly depends on the semantics of the node and/or payload > of the item being published. > > I think the only summary for a security consideration that covers all > the above is 'use your common sense'. Since this in general is a good > advice, I propose we don't add that to this specification, or any other > for that matter. I have summarized this information in my working copy as follows: *** In the context of instant messaging systems it is possible for the act of publishing an item to reveal the node owner or item publisher's network availability. However, this risk is mitigated by the following factors: 1. A node does not necessarily reveal the existing of the publishing entity. 2. XMPP PubSub systems are not necessarily tied to instant messaging systems. 3. Even in the context of IM systems, a node provides information distinct from network availability (e.g., user tunes). 4. Even then, the actual publisher might not be an IM user (e.g., an automated calendaring or geolocation system). *** /psa - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkquyCMACgkQNL8k5A2w/vxXKQCg2NoD35sb5IWLAXOsNVdT0yIk J5sAmwXp3PXQkYhAZzytCPlGS9zOCJsw =kQPH -----END PGP SIGNATURE-----
