W3C home > Mailing lists > Public > public-credentials@w3.org > October 2019

Re: "anybody can ledgerize" vulnerability

From: =Drummond Reed <drummond.reed@evernym.com>
Date: Mon, 14 Oct 2019 12:16:17 -0700
Message-ID: <CAAjunnZ6bg4a+pPzW6yjKPanQCHwZFP6DYq+NWXesqNMP9C4Uw@mail.gmail.com>
To: Brent Zundel <brent.zundel@evernym.com>
Cc: ProSapien Sam Smith <sam@prosapien.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>, Orie Steele <orie@transmute.industries>, Daniel Hardman <daniel.hardman@evernym.com>
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.


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

> 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.
Received on Monday, 14 October 2019 19:16:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:01 UTC