Re: On JSON-LD with DIDs and VCs

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

Received on Sunday, 12 January 2020 21:48:08 UTC