Re: "anybody can ledgerize" vulnerability

I nominate Sam Smith if he's willing to open the issue because his answers
on this thread have been spot on. I believe this issue should not only be
in the Security Considerations section of the DID spec, but it's important
enough to have its own subsection.

=Drummond

On Mon, Oct 14, 2019 at 10:52 AM Brent Zundel <brent.zundel@evernym.com>
wrote:

> Sam,
>
> Thank you for your explanation. And thanks to everyone for this
> discussion. As the DID Specification work moves forward, I would like to
> make sure we don't lose track of this concern.
> Would someone be willing to open an issue about it in the working group
> github repo <https://github.com/w3c/did-spec/issues>? That way the DID WG
> can try to address it.
>
> On Thu, Sep 19, 2019 at 12:11 PM ProSapien Sam Smith <sam@prosapien.com>
> wrote:
>
>>
>> Some additional comments:
>>
>>
>> The problem is that the DID Spec in its current form is sufficiently
>> ambiguous that it does not require self-certifiability but implies
>> (dangerously so) that complying with the spec without
>> self-certifiability is sufficient.
>>
>> Proving control of a DID, i.e., the binding between the DID and the DID
>> Document that describes it, requires a two step process:
>>
>>    1. Resolving the DID to a DID Document according to its DID method
>>    specification.
>>    2. Verifying that the id property of the resulting DID Document
>>    matches the DID that was resolved.
>>
>>
>>
>> This issue came up because the did:peer method  was designed to be
>> private and not put on a ledger, however, the current formulation of the
>> did:peer method suffers from the "anyone can ledgerize" vulnerability
>> precisely because it is not self-certifying.  So the ambiguity in the spec
>> is a problem.
>>
>> For example Veres one goes beyond the specification by ensuring that a
>> fingerprint of the verifiying key pair is in the DID itself. (ie is
>> self-certifiable)
>> Quoting Dave Longely:
>> "Veres One (v1) protects against this by requiring the DID itself to be
>> derived from key material. A Veres One "nym" (short for cryptonym) DID
>> must be derived from one of the `capabilityInvocation` keys expressed in
>> its associated DID Document. The act of registering the DID requires
>> that the DID Document itself be invoked as a capability
>> ("self-registration"). This invocation can only be performed by whomever
>> controls the private key material associated with a
>> `capabilityInvocation` key, and specifically, the DID itself must have a
>> fingerprint (or full public key material) that matches that key.
>> "
>>
>> A reasonable interpretation of the spec language allows one to NOT
>> include a fingerprint of the public key from the public/private key pair
>> used to sign the did document in the DID itself.
>> Merely that the id property matches the did  but the id property could
>> be anything and does not have to be cryptographically linked to the signing
>> key material provided in the did doc .
>>
>> This creates a race condition. As anyone can create key material and
>> register the DID (create method) with a DID resolver. Because DID resolvers
>> are decentralized it is up to the did resolver to decide which DID docs to
>> cache and which to not and if one wants to make sure one's did doc is
>> discoverable one has to register it it widely.  So a malicious party could
>> observe the registration of a DID at one resolver change the key material
>> in the did: doc and then register the same did but with different did doc
>> at  another resolver.  This is just another form of the anyone can
>> ledgerize attack. Its the anyone can spoof a did to a given did resolver.
>>
>>
>> Now  one way to stop the spoofing would be to add a ledger as a root of
>> trust in the did method where the DID method requires that in order to
>> CREATE a did at a resolver the resolver must first find the did on the
>> ledger with its did:doc.
>>
>> But now the DID is not portable across ledgers as the root of trust is
>> also the ledger not merely the controller of some private key.
>>
>> Fundamentally the mix of non-self-certifiability and decentralized
>> control is problematic.  It is possible to build a did method on other
>> roots of trust besides or in addition to self certifiability but its way
>> more complicated.
>>
>> The main value of a decentralized identifier standard is to enable any
>> entity to assert control over a namespace  without dependence on some other
>> entity in an interoperable way.  The infrastructure of DIDs DID Documents
>> and DID resolvers is to support than value.  But when the infrastructure is
>> also decentralized it becomes problematic when there is not a consistent
>> root of trust over the whole interoperable infrastructure.
>>
>>
>> When the key material used to verify a did doc is not linked to the did
>> itself then anyone can create a did doc for that did and use different key
>> material. That is the problem.  When that happens there is no unique
>> controller of the DID unless some other root of trust or authority
>> specified in the DID method is invoked to determine the unique controller.
>>
>>
>> Because DID specification punts the control of DID methods and DID method
>> namespaces to a "market solution" removing self-certifiability opens up
>> another lurking problem.   Frankly the market solution  may be the best
>> we can do for now.  What this means is that DID resolvers get to decide
>> which did methods for which did method names they will support. Different
>> resolvers could decide to support a different method for the same method
>> name given two different entities that wish to control the same method
>> namespace. One hopes that the cost of maintaining a method name space makes
>> method name squatting a rarity. One hopes that resolvers will have
>> reputations that enable users to pick credible resolvers.
>>
>> But realistically :)
>>
>> There is incentive for a malicious entity to  confuse the did method and
>> did method name from the standpoint of the user wishing to resolve a did at
>> a given resolver.
>>
>> 1) A malicious attacker could substitute a malicious method into a local
>> resolver.
>>
>> 2)  A universal resolver that allows automatic registration of DID
>> methods would be a target for malicious did methods.
>>
>> 3) A business dispute between partners who have created a method
>> namespace where there is no legal basis for who gets to control the method
>> namespace. So the partners each spam new resolvers with a different version
>> of the method.
>>
>> BUT in any case if the DID itself is self-certifying then attacks on
>> methods at resolvers are limited because the user can always independently
>> verify the root of trust in the did doc.  Removing that root of trust just
>> opens a can of worms. Putting the root of trust solely  in the DID method
>> does not close the can.
>>
>>
>>
>>
>>