Re: ActivityPump and signature / origin verification

On 12/20/2015 10:53 AM, Jason Robinson wrote:
> Hey all,
>
> The current ActivityPump draft specifies the following things [1]:
>
> /> Servers //SHOULD//validate the content they receive to avoid
> content spoofing attacks. In particular, servers //SHOULD NOT//trust
> client submitted content, and federated servers also //SHOULD
> NOT//trust content received from a server other than the content's
> origin. The general mecahism that is specified for this at this time
> is for a recipient of some referenced activitystreams object to verify
> the presence of that object on the original server. Other mechanisms
> such as verifying signatures are left out of scope of this document.
> (However, if other generally agreed upon mechanisms for handling
> verification become available in the future, servers are welcome to
> use those methods, in the future.) //
> /
> Two things I have problems with in this spec:
>
> *Signature verification*
>
> I think any good standard for a federated web protocol should contain
> at least a SHOULD to signature verification. Ideally, to provide
> reliability to content ownership, received content (server to server)
> SHOULD be 1) signature verified and 2) presence verified (for content
> type messages). Both checks are important for different reasons.
>
> At least when looking at diaspora*, redmatriz/hubzilla and AFAICT GNU
> Social and Friendica, signature verification is *THE* way to verify
> content.
>
> Another hard to solve problem that needs signature verification is
> identity backup / restore and migration. This is something that afaik
> is only supported on Redmatrix/Hubzilla, from what I know. I've
> drafted some ideas on a possible solution in the diaspora* wiki - and
> it relies on signatures [2]. The idea is to make sure identities can
> be automatically backed up and migrated around.
>
> What are the reasons why we wouldn't have signature verification when
> receiving content from other servers?

FYI, I'd recommend using JSON Web Signatures with JSON Web Tokens for this?

@@

In terms of signatures, just make sure to bake-in some signature
agility, but for the time being P-256 and large RSA should be supported.
The WebCrypto API would allow JS to verify and sign AS2.0 quite easy -
in fact, Thoughtworks already implemented this.

JWS
https://www.rfc-editor.org/rfc/rfc7515.txt

JWT:
https://www.rfc-editor.org/rfc/rfc7519.txt

See libraries:
http://jwt.io/

Many large company information flows use this already, so it works. Key
retrieval via a simple modification of WebFinger might be a good idea as
well, but this may want to remain underspecified - although there's some
revived and likely more reviving work on receiving keys and key servers
in the IETF as well.

>
> *Content received from*
>
> Another problem with the current draft I see is the "SHOULD NOT trust
> content received from a server other than the content's origin".
> Federated web is hard, especially in scaling. We've already built a
> special decentralized relay system [3] that is supported by diaspora*
> and Friendica at the moment, which would simply not be possible if all
> content MUST be delivered from the source. Verifying signatures allows
> this kind of load balancing of moving content around because the
> target node will always make sure the message is from the person it
> claims to be from.
>
> Verifying signatures and allowing content from non-author locations
> will also enable the possibility of not always online federated
> servers, for example in desktops and mobile phones. These would rely
> on "postman" type of relay servers to keep content targeted to their
> server and fetch it on demand. These are afaik just theoretical at the
> moment, but having a SHOULD NOT trust except from original location
> would kill the possibility for anything like this.
>
> Not having this SHOULD NOT in the spec of course means that the
> content should be signed and verified against the public key of the
> author.
>

Agreed with general observations, but note that there's
caching/scalability that keeps the same origin and there's also the old
pubsubhubbub specs that did signature verification, although their specs
are quite out of date in terms of aforementioned work. So updating that
general stream of work with recent IETF specs and a social usecase would
I think be a grand idea, and the Diaspora wiki is a good start.
> Opinions?
>
> [1]: http://w3c-social.github.io/activitypump/#obj (2nd paragraph)
> [2]: https://wiki.diasporafoundation.org/Relay_servers_for_public_posts
> [3]: https://wiki.diasporafoundation.org/Account_Backup_And_Restore
>
> -- 
> -----
> Br,
> Jason Robinson
> https://jasonrobinson.me