Hey Pádraic, Sorry for the delay in my response. Been a busy October! Thanks so much for the detailed response. I've got some followup.
> My point, if anything, is that we are dividing what we protect and > subjecting all of it to a defence which is already implemented quite poorly > in practice. On the one hand, we have a signature for request bodies, and on > the other hand, nothing for headers. If the SSL/TLS protection held true - > why even rely on body signatures at all? Why: Because the SSL/TLS request coming from the hub is of unknown origin (unless you use SSL *client* certs, which is never going to happen). You use the body signature as a bearer token to verify the authenticity of the Hub that's pushing the new content to subscribers. > In this scenario, SSL/TLS becomes a single point of failure in a system > where failure is not only common but sometimes encouraged. In a network of > Hubs and Subscribers where parties may fail to verify certs, MITM attacks > will be possible. Extending from that, not signing ALL components of the > request will allow for requests to be manipulated without invalidating the > signature of whatever subset of data is signed. The body is signed by an HMAC of a shared secret and the content. Even if the hub *never* validates server certs for subscribers, the message will not be subject to replay attacks unless the SSL connection itself is compromised. The existence/chance of such MITM attacks in the wild is low. My claim is that hubs who care about the privacy of the data they distribute should verify server certs properly and require valid CA-signed subscriber certificates. > That's why signatures remain compelling. Yes, they are a pain in the ass to > develop. Yes, they can lead to incompatibilities between large posterchild > implementations. Yes, programmers hate them with a vengeance. Why? Because > programmers can't ignore them by setting curl's peer verification to false. > They actually have to go and deal with them properly or nothing will work. > In a sense, they are supposed to be a PITA. The problem with this conclusion, as I see it, is that full signing is way too hard and people won't do it. There are rare exceptions to this (the Twitter API) that have much more to do with the current market conditions than technical considerations. So in this proposal I'm trying to split the difference of usability vs. security. Thus far, every proposal I've seen for arbitrary content type support in PubSubHubbub requires a level of complexity in signing that is approaching that of OAuth1.0 (a bad thing). If the alternative is way easier but requires hubs to do proper server cert validation, is that worth it? A potential alternative approach to this is the up-and-coming signing standard: http://developers.facebook.com/docs/authentication/canvas Which I hear will be integrated into OAuth2: https://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4&pli=1 We could try to use that for a combined body/header signing scheme. It could use HMAC-SHA1 as the signing algorithm and using the shared secret established during subscription time to sign the message. -Brett
