Re: payswarm vocabs http vs https

On 26 January 2013 06:10, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 01/25/2013 09:02 PM, Manu Sporny wrote:
> > #4 is dangerous. JSON-LD does have a feature where it allows you to
> > load any other context from the Web. Those contexts can override
> > 'source' and 'destination'.
>
> Dave Longley and I just talked this attack vector through and it doesn't
> seem like it's a valid attack. Here's the attack in a nutshell:
>
> 1. A buyer is attempting to swap the source/destination fields on who
>    gets paid for a particular asset. There are two places that they
>    could corrupt the source/destination: the listing, the contract
>    before payment is made.
> 2. The buyer finds a seller that is overlaying their own JSON-LD
>    context and poisons the DNS that the seller is using to load their
>    own context. The buyer's poisoned context swaps source/destination
>    in the PaySwarm listing.
> 3. The buyer poisons the PA's DNS with their poisoned context that
>    swaps source/destination in the listing and the PaySwarm contract.
>
> #2 fails because swapping source/destination in the listing creates an
> invalid payee for the digital good. The PaySwarm Authority will reject
> the listing because it doesn't contain a destination field.
>
> #3 fails because the PaySwarm Authority (and this part is implementation
> dependent) uses the listing to figure out who should be paid what, and
> the listing is invalid at this point. Even if the listing were valid,
> the poisoned JSON-LD context isn't applied until /after/ payment is
> made, so the money would still go to the right place. The poisoned
> JSON-LD context could still be written to the database with
> source/destination swapped, which would cause a transaction audit to
> fail, at which point the attack would be detected.
>
> So, a successful attack results in no monetary damage, but a corruption
> of the transaction record (that is easily detected and fixed).
>
> However, that this attack didn't work out is just a result of the way
> PaySwarm is designed. There could be other fields that the seller could
> sign in the future that would affect the flow of payment. So, it's
> probably best that we implement some sort of more heavy-weight
> requirement that all JSON-LD Contexts used in PaySwarm transactions MUST
> be loaded over HTTPS. This makes it so that implementers don't have to
> worry about this sort of attack vector at all, which will simplify
> implementations and lead to a tighter security model in general.
>
> I've raised an issue in the JSON-LD group to discuss the issue in more
> depth:
>
> https://github.com/json-ld/json-ld.org/issues/213
>

Thanks for the detailed response.  I wonder if we could get the vocabs
under the w3c namespace?  Timbl was taking last week at davos about the
need for new payments protocols...


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Aaron Swartz, PaySwarm, and Academic Journals
> http://manu.sporny.org/2013/payswarm-journals/
>
>