Secure notification of arbitrary content using Salmon Magic Signatures

[Bob Wyman]

Julien suggests that a new mechanism is required to provide secure notification when sending arbitrary content. 

One useful and simple approach to this problem is provided by the "Magic Signature" method of the Salmon Protocol. 

If one assumes that the primary concerns for security involve ensuring that data tampering and authorship can be detected, the Magic Signature approach should do the job well. It would not, however, be suitable if the intent is to publish "secret" data.

See: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html

bob wyman

[Jeff Lindsay]

Alternatively, many people implementing webhooks (PSHB being one example) use an HTTP header for signing. So far everybody does it differently. I like Magic Signatures, I also like the loosely inspired JWT, but I feel like something that lives in the headers is the Right Way to do this. 

There is a very rough draft for something that could solve this problem:

http://tools.ietf.org/html/draft-burke-content-signature-00

I've been recommending it to people looking at signing their webhook payloads. It's not exactly usable yet, but I think it's a good thing to think about. Perhaps we can borrow semantics from Magic Signature and put them into Content Signature?

-jeff

--
Jeff Lindsay
http://progrium.com

[Bob Wyman]

HTTP headers are global to the entire message being transmitted. So, if the message body is aggregated from multiple sources, each of which signed their originals, how would you match signatures in the header to subcomponents of the message in a format-independent manner? Or, do you simply say that aggregation isn't supported?

A hub may wish to sign a message that was signed by its publisher. This message might then be sent to another hub that also wanted to sign it, etc... In this case, if the signatures are in the header, who signs what and how do you keep the signatures distinguished from each other?

bob wyman

[Jeff Lindsay]

HTTP headers are global to the entire message being transmitted. So, if the message body is aggregated from multiple sources, each of which signed their originals, how would you match signatures in the header to subcomponents of the message in a format-independent manner? Or, do you simply say that aggregation isn't supported?

My immediate thought is to use multipart messages. But maybe that's not as easy to work with.

 

A hub may wish to sign a message that was signed by its publisher. This message might then be sent to another hub that also wanted to sign it, etc... In this case, if the signatures are in the header, who signs what and how do you keep the signatures distinguished from each other?

Yeah, this is what Salmon and Magic Signatures were designed for, right? My initial reaction is that we should probably rethink the need for hub federation. Maybe Julien can comment, but I don't think it's actually that useful in practice. That said, as a consumer, I can only imagine caring about the hub I subscribed to and maybe the content publisher. 

But that brings up an interesting point: hub and publisher signatures are not really the same. The publisher is not making HTTP requests, they are providing content. So they would sign at the content level (if at all, it's an edge case right now). The Hub is making HTTP requests, so signing at the HTTP level via Headers makes sense (and doesn't pollute the content). 

-jeff

 

bob wyman

On Sun, Nov 20, 2011 at 6:20 PM, Jeff Lindsay <prog...@gmail.com> wrote:

Alternatively, many people implementing webhooks (PSHB being one example) use an HTTP header for signing. So far everybody does it differently. I like Magic Signatures, I also like the loosely inspired JWT, but I feel like something that lives in the headers is the Right Way to do this. 

There is a very rough draft for something that could solve this problem:

http://tools.ietf.org/html/draft-burke-content-signature-00

I've been recommending it to people looking at signing their webhook payloads. It's not exactly usable yet, but I think it's a good thing to think about. Perhaps we can borrow semantics from Magic Signature and put them into Content Signature?

-jeff

On Sun, Nov 20, 2011 at 1:56 PM, Bob Wyman <b...@wyman.us> wrote:

Julien suggests that a new mechanism is required to provide secure notification when sending arbitrary content. 

One useful and simple approach to this problem is provided by the "Magic Signature" method of the Salmon Protocol. 

If one assumes that the primary concerns for security involve ensuring that data tampering and authorship can be detected, the Magic Signature approach should do the job well. It would not, however, be suitable if the intent is to publish "secret" data.

See: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html

bob wyman

--
Jeff Lindsay
http://progrium.com

[Farrukh.najm]

I believe ebxml messaging protocol may be worthwhile studying for how to handle message level security in a multi-hop scenario.

--Farrukh Najmi

-------- Original message --------
Subject: Re: [pubsubhubbub] Secure notification of arbitrary content using Salmon Magic Signatures
From: Bob Wyman <b...@wyman.us>
To: pubsub...@googlegroups.com
CC:


HTTP headers are global to the entire message being transmitted. So, if the message body is aggregated from multiple sources, each of which signed their originals, how would you match signatures in the header to subcomponents of the message in a format-independent manner? Or, do you simply say that aggregation isn't supported?

A hub may wish to sign a message that was signed by its publisher. This message might then be sent to another hub that also wanted to sign it, etc... In this case, if the signatures are in the header, who signs what and how do you keep the signatures distinguished from each other?

[Julien Genestoux]

Bob, could you clarify how magic sigs would work? I am under the impression that the turduckin problem would still be there (but I'm probably missing something?).

Jeff, I like the idea of the spec you proposed. Do you know of any use case currently out there?

Julien

[Martin Atkins]

On 11/20/2011 03:36 PM, Bob Wyman wrote:
> HTTP headers are global to the entire message being transmitted. So, if
> the message body is aggregated from multiple sources, each of which
> signed their originals, how would you match signatures in the header to
> subcomponents of the message in a format-independent manner? Or, do you
> simply say that aggregation isn't supported?
>
> A hub may wish to sign a message that was signed by its publisher. This
> message might then be sent to another hub that also wanted to sign it,
> etc... In this case, if the signatures are in the header, who signs what
> and how do you keep the signatures distinguished from each other?
>

I think two separate needs are being discussed here:

* A subscriber needs a way to determine whether an incoming push
notification did indeed come from the expected hub. In this case it is
the entire message -- possibly *including* the HTTP headers? -- that
needs to be authenticated.

* A publisher is re-publishing something from another source and the
subscriber needs a way to verify that it did indeed come from the other
source. In this case it is the higher-layer messages that need
authenticating, and Salmon Magic Signatures seems like a fine way to do
that but that seems out of scope of PubSubHubbub since it's specific to
the data format being transmitted.

[Bob Wyman]

Salmon Magic Signatures are not, in fact, "specific to the data format being transmitted." Both an XML and JSON encoding for the signatures is provided, however, the format of the signed payload is not defined by the Magic Signature Specification. Anything that can be base64url encoded can be the signed payload of a magic signature.

bob wyman 

[Jay Rossiter]

They're not specific in the way that signing for JPEG is somehow
different than signing for PDF, but they are specific to XML or JSON,
as you've just stated. You can't just send an arbitrary file and have
it be "signed" unless it is encapsulated in another format.

I do agree with Martin that there are two separate things being
discussed, however. One is content validation, and one is source
validation. I've never, personally, seen the benefit in adding the
content-specific validation to PuSH. It's really an external issue.

Validation that the content actually originated from the correct hub
is important, because it's possible for endpoints to be leaked and
abused without it.

On Nov 22, 12:51 pm, Bob Wyman <b...@wyman.us> wrote:

[Bob Wyman]

On  Tue, Nov 22, 2011 at 4:52 PM, Jay Rossiter <jros...@dlvr.it> wrote:
> I've never, personally, seen the benefit in adding the 
> content-specific validation to PuSH. 

Imagine that the "arbitrary content" that I am pushing is an "offer-to-buy" or an "offer-to-sell." (i.e. It is a message whose authenticity is critical to its utility.) You are likely to want to have some reason to believe that I did, in fact, publish these offers. Certainly, it is interesting for you to believe that the hub that sent you these offers is, in fact, the one that you expected, however, you can't really be sure what the chain of delivery was prior to the hub and thus you can't be sure that the offers weren't tampered with prior to being processed by the hub that you trust (Garbage in, Garbage out.).

Yes, you could "validate" the authenticity of the offers by actually tracking down the source feeds and reading the data from the original. But, then you'd be using PuSH as a notification service rather than a content delivery service. You would also be requiring me to maintain my feeds on an open, connected server and, because you're using PuSH as a notification service, you would be part of creating precisely the "thundering  herd" problem that PuSH is designed to eliminate.

An added advantage of having the content signed, rather than just the session link, is that you can then store the data in a form that can easily be validated or re-validated at a later date and you would be able to re-syndicate the data without anyone needing to fear that you had tampered with it.

bob wyman