Re: On JSON-LD with DIDs and VCs

On Sat, Jan 11, 2020 at 9:29 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 1/10/20 7:58 AM, Oliver Terbu wrote:
> > If DID Doc consumers have "remote context retrieval" enabled for
> > arbitrary URIs
>
> Don't do this in production... ever. :)
>

That is great, then we should add a normative statement to the spec such as
"JSON-LD processors MUST not use remote context retrieval" and I will be
happy. Because this is JSON-LD specific, this should be added to a separate
document.


>
> The attack you are concerned about is completely mitigated by not
> allowing software to arbitrarily download and execute code from the
> Internet.
>
> This is a general security practice in any software system.
>
> If you are writing production grade software and security is a concern,
> don't let your software retrieve random documents from the Internet.
>
> With respect to the attack you outlined, there is zero difference
> between *properly implemented* JSON processors vs. JSON-LD processors.
>

The JSON-LD spec allows "remote context retrieval". The JSON spec has
nothing like that. Because that is a feature of JSON-LD that is not needed
and not desired, we should explicitly discourage this feature by
introducing normative language. People were talking about other JSON-LD
best practices such as strict mode etc. to be considered as a *proper*
implementation. Let's make that normative as well.

My point is that I'm not happy with the answer that just because something
is best practice, so people will use it. We should have the mindset that
everything that is allowed, can happen. If 0.01% of JSON-LD implementations
are doing that wrong, then this is already 0.01% too much that could have
been prevented easily by mandating certain things and defining a normative
JSON-LD profile for DIDs.


> > Please note, that this is not an exhaustive list of attacks. It
> > would take quite an effort to identify all vulnerabilities that are
> > potentially(!) enabled by just using JSON-LD.
>
> You have, to date, identified zero successful attacks for properly
> implemented systems using JSON-LD.
>

I always said that the described attacks target implementations that don't
follow these best practices. Let's add a normative statement to the spec to
resolve that issue. This will allow the industry to come up with
certification programs in the future.


>
> > Additionally, I want to explicitly note, that I'm not saying that
> > there are no attacks possible on JSON-only DID Docs. But it will have
> > a different risk profile.
>
> You have yet to produce a single attack model that differentiates a
> proper JSON implementation from a proper JSON-LD implementation.
>
> ... but this is fun, keep going. :)
>
> We should be critical of these systems and try different attack models
> to see if there are vulnerabilities.
>

Yep, that is fun :) . I agree, we should think more about attack models. I
didn't have much time since my last email. Let's talk at the W3C DID WG
meeting how to proceed with this work. It would be great to start some sort
of catalogue. We did some work in this area already but the docs cannot be
shared.


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>