Re: ActivityPump and signature / origin verification

Jason Robinson writes:

> Hey all,

Heya Jason,

Sorry it's taken so long for me to reply to this.  Holidaze, and all
that.  Also I'm on a train moving myself to San Francisco for 4 months
so there's that.

Replies below!

> 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?

I've long been interested in signature verification in ActivityPump.
The current method of verifying things means checking anything of not
same-origin means looking it up *on* the origin and verifying the
content (which really means there's no point in distributing remote
content anyway since it needs to be verified).  Indeed, signatures seem
to make a lot of sense to me personally.  BUT!

a) It seems like what the future of signatures on the web is going to be
   is not really well agreed upon yet.  My understanding is that it's
   considered generally out of scope of the group to get involved in
   acknowledging or denying any official solution.

b) In fact at the SocialWG face to face in San Francisco at Mozilla last
   month I raised the signature thing and how I'd like to have it, and
   there was a firm reply that it was out of scope, and every attempt to
   get this right usually gets it wrong, and then Evan looked at me
   right in my face and said very sternly something like "I don't want
   to *hear* about signatures in the context of this group."  I got the
   message.

My impression is that this wariness towards signatures comes from
headaches in previous implementations, I think especially with Salmon.
But hey, maybe Evan can chime in on what he meant (or correct my
quasiquote above).

> *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.

Despite what I just said above, the signature aspect is important to me,
and I agree that we shouldn't do anything that prevents clear solutions
from being adopted once what they exactly are gets sifted through
clearly.  Hence me adding the "if other generally agreed upon mechanisms
for handling verification become available in the future, servers are
welcome to use those methods, in the future" phrasing.

If you're worried this SHOULD NOT still blocks it, I can change it.

In the meanwhile, what should we do about signatures?  Harry suggested
one route via the JOSE type direction, and I think really there's two
competing routes available which are moving forward, the other one
possibly being the work the Web Credentials community group is doing.
I'm watching both carefully.  I'll withhold my opinions on what I think
the sure future is... I have inklings but it's too soon to tell for
anyone.  And I agree with the comments at the last face to face that
it's not the space of this group to stake to one direction here.

That said, maybe post-activtypump, when things do settle down, we can
make a future recommendation or something.  (Or maybe it will be so
obvious by then we won't need to.)

Sadly for the moment I'm afraid we're only recommending one path to
verification, but as I said, I want to make sure that the spec doesn't
block future other signature based methods.  Do you have a suggested
edit to the above wording to make it avoid that problem?  You could open
a pull request and I'll happily review it...

Thanks for commenting on this, I agree it's important!

 - Chris

Received on Monday, 4 January 2016 14:16:06 UTC