Re: Bag of Data Anti-pattern (was: Re: DID Spec Closure Process: Harmonize our two Cryptographic Key Material Proposals?)

Manu Sporny writes:

> On 12/27/2017 02:16 AM, =Drummond Reed wrote:
>> It would allow developers or applications who prefer "naive JSON" to
>> use the DID document for basic key management with a simple array of
>> keys described by type.
>
> Before proposing something, it's important to identify a
> standards-making anti-pattern that we keep coming back to in this
> discussion. Let's call it the "Bag of Data" anti-pattern for now, and it
> goes something like this:

[... snip ...]

> Let's now apply this principle to what's being suggested in "Proposal
> #1: Simple Flat Array of Key Description Objects":
>
> {
>   "keys": [ ... ]
> }
>
> This data structure raises the following questions:
>
> Q1. Are those keys the DID owns or any key that the DID document
>     references?
> Q2. Are all software applications allowed to add/remove any key in that
>     array, or just a subset?
> Q3. Can I put a biometric authentication mechanism in that array?
> Q4. Can I specify a key reference into that array, or can I put
>     complete key descriptions elsewhere in the document?
>
> As a developer, I could easily jump to the conclusion that:
>
> A1. All keys must go in this array, including descriptions of other
>     people's keys.
> A2. Any software application is allowed to manage any key in that array.
> A3. Biometrics should not go in that array.
> A4. I must put all keys in that array and nowhere else, even if they're
>     buried deep in another subtree of the data structure.

It may be useful to look at how having a more general key bucket can
lead to some real security vulnerabilities.  First off, I really
recommend reading this article:

  https://sandstorm.io/news/2015-05-01-is-that-ascii-or-protobuf

In that article a scenario is given where you use your key to respond to
an arbitrary-looking random string in a challenge-response type system
to prove that you are who you say you are.  Sounds good... except it
turns out that that random looking string was actually a datastructure
that was asking you to authorize a payment, and your client signs it.

  "Oops, it appears you just signed a bank check after all – and you
  were trying so hard not to!"

We can easily imagine such attacks in our own domain.  Imagine someone
is using their DID + key materials for the following purposes:

 - In a peer to peer protocol where nodes are signing that yes, they
   really did see another node produce this object at a particular time
 - An authorization of payment, or anything else serious (surgery,
   sharing of private information, selling your house, etc)

Without distinguishing between the function of keys, it would be
possible to trick a node into performing the former with a key in their
general keys bucket but to use that object for the latter purpose.
A verifier being presented the object in the context of the latter
purpose (but which was signed by the node under the former purpose) may
say "oh yes, all looks good here... go forward with that payment /
surgery / sale of house!"

That seems like a serious issue to consider?

 - Christopher Lemmer Webber

Received on Wednesday, 3 January 2018 20:03:44 UTC