RE: On JSON-LD with DIDs and VCs

Manu >> If you are writing production grade software and security is a concern, don't let your software retrieve random documents from the Internet.
…
Oliver >> that just because something is best practice, so people will use it. We should have the mindset that everything that is allowed, can happen

I agree with Oliver that if developers who are not steeped in the security nuances (or do not care even if they are aware) will always take the easy way out, whatever the “best practice”. So providing strongly worded guidance w/o corresponding enforcement ends up being nothing more than a feel-good dust in the wind pointer to how thoughtful the standards creators were.

I came up in the world where we realized that standards in general are the result of compromise arrived at by people with different motivations and knowledge bases and as such what is more important is to come up with a ‘Profile’ of a standard where you constrain the options that are available within a standard to achieve particular goals whether that goal is security, privacy and/or interoperability.

If this is such a clearly bad idea, what are the implications of constraining how JSON-LD can be utilized within the DID Core Spec and/or DID Resolution Spec to prevent/limit remote context retrieval rather than leaving it open ended with the end goal that any DID spec conformance test suite fails hard if that constraint is not in place?

Best Regards,

Anil

Anil John
Technical Director, Silicon Valley Innovation Program
Science and Technology Directorate
US Department of Homeland Security
Washington, DC, USA

Email Response Time – 24 Hours

[https://www.dhs.gov/science-and-technology/svip]


From: Oliver Terbu <oliver.terbu@consensys.net>
Sent: Monday, January 13, 2020 9:00 AM
To: David Chadwick <D.W.Chadwick@kent.ac.uk>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: On JSON-LD with DIDs and VCs

I cannot get my head around this. If remote context retrieval is part of the JSON-LD spec and this is used in the course of JSON-LD validation, then this is in scope of the DID Core Data Model spec. Would you agree?

If people don't believe this belongs into the DID Core spec, then I would argue it should be at least in the DID Resolution spec and we should make it normative there.

Oliver

On Sun, Jan 12, 2020 at 10:49 PM David Chadwick <D.W.Chadwick@kent.ac.uk<mailto:D.W.Chadwick@kent.ac.uk>> wrote:
+1 to adding statemens to the Implementation Guidelines to prevent
remote retrieval. I dont think they can be added to the data model
standard since protocol is out of its scope

David

On 12/01/2020 20:45, Oliver Terbu wrote:
> On Sat, Jan 11, 2020 at 9:29 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>
> <mailto:msporny@digitalbazaar.com<mailto: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

>