On Sat, Jan 30, 2010 at 11:39 AM, Josh Fraser <[email protected]> wrote: > If you switch to fat pings you open yourself up to spoofing.
This issue is being addressed by the Salmon<http://www.salmon-protocol.org/>protocol and it would make a great deal of sense, I think, for PSHB and Salmon to evolve common solutions. Of particular interest for this discussion would be the mechanisms that Salmon is defining for publishing "signed" data. See John Panzer's recent post concerning "Salmon Magic Signatures" at: http://www.abstractioneer.org/2010/01/magic-signatures-for-salmon.html The approach to PKI and signatures taken in the Salmon specs is vastly more simple than that which has traditionally been used. However, even though simpler, the Salmon approach provides all the capabilities needed for systems like Salmon or even PSHB. When thinking about "Fat Pings" in a context like PSHB, we need to be very careful to understand the fundamentals of the "thin ping" system that "fat-pings" would replace or augment. For instance, one of the key assumptions in a "thin-ping" system is that the actual data of interest exists in some feed and can be retrieved from that feed. In such a system, pulling data from the feed not only provides us with access to that data, it also gives us information about *who* published the data -- i.e. someone who has the ability to create a feed with the given URL. In a thin-pinging system, we don't have to worry a great deal about "spoofing" (publishing items that make false claims about their source feeds) since all items are read from feeds. However, in a "fat pinging" system, spoofing may be a problem since forcing consumers to read feeds is precisely what fat-pinging system seek to avoid. A "Fat-pinging" system that uses signatures, like Salmon does, allows readers of fat-pings to have the same level of confidence concerning the origin of an item that a thin-ping consumer has. In Salmon, all signed data includes a WebFinger <http://code.google.com/p/webfinger/> identifier which is linked to the public key of the signer. This makes it very easy to ensure that whoever has control over the WebFinger identifier was, in fact, someone who signed the item. Now, WebFinger is usually used with things that look like email addresses, however, there is no reason why we couldn't also use identifiers that look like feed URLs as well. Thus, we could use feed URLs as identifiers to find the public keys needed to verify the signatures on Fat-Ping data claiming to come from a particular feed. The result is that without looking in a feed, we could then verify that the a particular piece of data was, in fact, created by someone who had the ability or permission to create items associated with feed. (i.e. the same level of assurance that we get from reading an item from a feed.) Of course, using signed-fat-pings, we also have the ability to verify the source of items after they are no longer available in the source feed (many such feeds are limited to the number of items they provide and "drop" stuff over time). Using signed-fat-pings, we're also able to allow downstream readers, no matter how many server hops may separate them from the origin feed, to verify the authorship of an item. It seems to me that the simple approach to signatures that is being developed for Salmon provides what is required by other "fat-pinging" systems -- including PSHB. Rather than inventing something new, why not just use the Salmon stuff? bob wyman On Sat, Jan 30, 2010 at 11:39 AM, Josh Fraser <[email protected]> wrote: > Isn't the real challenge around protecting the hub from spoofing? The > way it is now it doesn't matter if someone fakes a ping to the hub as > the hub will fetch the feed for itself and verify it. If you switch > to fat pings you open yourself up to spoofing. You could add another > form of authentication to deal with this, but it starts to get more > complicated. Not to mention the challenge of getting data > normalization right on the publishers end when one of our core > guidelines is "keep the complexity at the hub" > > On Jan 26, 10:22 pm, todd hoff <[email protected]> wrote: > > My understanding is that there's a light ping from the publisher to > > the hub. It would be convenient to use a fat ping here for the same > > reason as a fat ping makes sense from the hub to the consumer. > > Especially for low power devices the extra operations are a bit of a > > drain. >
