Re: ActivityPump and signature / origin verification

Hi,

Yes I was thinking of moving the discussion into a few issues on github 
- holidays too ;)

To me, content verification is pretty much central in any attempt to 
have a federation protocol - so I'm not sure how it could be outside 
scope ;) I understand there is want to use something that is also a 
standard and if there are two ways to go forward, that might be 
problematic. I don't really know either one, I'm just used to the good 
old and works way of reading a public key from the users profile and 
then verifying the content which is signed with the users private key. 
All protocols I've come across use good old public/private keys. I must 
confess this is not that many protocols, but to me this is a very simple 
and effective way - it is old technology which is proven and available 
everywhere and also easy to use. I'll post an example workflow from 
diaspora* into github.

The only problem I see with pubkey/private key -way is that is you lose 
your private key, you pretty much lose your identity - or at least 
ownership of any old content pushed out remotely. I'm not sure if the 
new signature methods being discussed solve this problem somehow.

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


The problem is that you can't remove the SHOULD NOT unless something 
else is offered in place. An even worse spec would be that would not 
provide a good way for verifying content authorship - leaving it 
completely open to the implementer. This is one of the most critical 
things imho in the whole idea of pushing content around - how to make 
sure the person really wrote that?

On the other hand, leaving that in, it would be impossible to build for 
example something like diaspora* purely with the protocol. And adding 
anything on top would make it largely incompatible with the rest of the 
implementers that enforce different trust requirements.

Anyway, will file some issues in github, better than mailing list :)

Br,
Jason
https://iliketoast.net/u/jaywink

On 04.01.2016 05:06, Christopher Allan Webber wrote:
> 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
>

-- 
-----
Br,
Jason Robinson
https://jasonrobinson.me

Received on Monday, 4 January 2016 21:12:34 UTC