Re: ActivityPump and signature / origin verification

On 01/07/2016 09:04 AM, Christopher Allan Webber wrote:
> Jason Robinson writes:
>
>> 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.
> I don't know the history to know why the objections to signatures have
> been so strong.  But perhaps others in the group do.  Would someone else
> like to chime in?
>
> We do have *a* method of verification, it's just not a very good one,
> because it doesn't rely on signatures and requires phoning back to the
> original source.  I agree that signatures would be better.
>
> I feel like my hands are tied here though in terms of making something
> official.  Jason, would you be interested in collaborating in something
> unofficial?

I'd also like to note we have some running code here too. The Objective8
platform (Clojure based, waiting for IE approval) implemented JSON Web
Signatures.

https://tools.ietf.org/html/rfc7515

There's mature libraries for most languages:

http://jwt.io/

Again, there are technical problems around how you would refresh
signatures and who actually signs what (i.e. is the 'pod'/server or the
user). However, any standard can probably punt on these and leave it
per-implementation.

I would support key discovery more or less in this order: via hCard (or
any other transformation of an hcard material), WebFinger/.wellknown,
and an option to look even at a keyserver (Google is working on new
public key servers for Google e2e, or just look at old ones like
pgp.mit.edu). Again, just chose 1-3 ways of retrieving key material.

I'm also happy to work with some cryptographers who are interested in
this sort of thing to double-check out security/privacy considerations.
I know George Danezis is interested in this issue, as are the folks from
Debian (Micah, Elijah, etc.) who are working riseup.net's next
generation decentralized e-mail end-to-end encryption software and the
social networking Crabgrass project.

       cheers,
           harry



>
>>> 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 :)
> There are two concerns here:
>
> 1. That saying SHOULD NOT effectively blocks *any* signature based
>    verification.
> 2. That a method of signature based verification is not specified,
>    meaning that in reality we'll have incompatibilities between instances.
>
> As for #1, I've revised the text in a way that I think makes more
> explicitly clear what is meant.  The "SHOULD NOT" is preserved, but
> "without some form of verification" is added.  I think this makes it
> clear that options are open to signature based verification if it's
> mature enough.
>
> -      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.
> +      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 without some form of verification.
>
> As for #2, as I said, I feel like we don't have a lot of leeway here.
> We're in the same boat here (sort of) that we are with authentication.
> Technically, in order for both the client to server and federation
> aspects of this protocol to work, we need to have an agreed-upon way of
> doing authentication, but also it's been made clear that we need to
> leave the actual mechanisms of this out of scope of the documents.
>
> Except, I guess, that the document actually acknowledges that
> authentication is needed, and doesn't acknowledge that signature
> verification is :)
>
> Anyway, I hope the wording change helps, and happy to talk further.
>

Received on Thursday, 7 January 2016 14:54:22 UTC