How to mitigate the single source of failure wrt/ "Trust into the Universal Resolver"?

[cstoecker]

Note: The following proposal is inspired by the lightweight slock.it incubed concept for verifying read transactions from a remote blockchain node.

Problem Statement

As as user of DIDs I need to have an instrument to resolve a DID and retrieve the respective DID document. In many cases people do not run their own resolvers and they therefore need to trust a third party operating a so called universal resolver. As a user I am exposed to the threat that the universal resolver is not responding the correct DID document that is stored on the respective blockchain.

Key Question

How do I, as a verifies, mitigate the risk of interacting with a malicious universal resolver implementation?

Assumptions & pre-conditions

1. DID document is stored in one block on the blockchain (for simplification only).
2. Cross-validation network of multiple universal resolver implementations.
3. Curated registry of cross-validation uni resolver implementations.
4. I - as a verifier - choose an arbitrary universal resolver implementation as a primary "access resolver" for submitting my DID document request.
5. In addition, I choose further arbitrary chosen universal resolver implementations as "validators".
6. No encoding / decoding being done by the universal resolver.

Proposed solution scenario

The verifier client sends a request to a randomly chosen access resolver implementation of the cross-validation network along with a list of validators.

The access resolver implementation executes the request, creates the DID document response and assembles the proof data needed so that the verifier client can to verify the DID document result. Prior to assembling the proof data the access resolver is requesting the signed block hash from the validators.

The proof data assembled by the access resolver consists of the following components:

• block hash and full block header of the block where the DID document payload data is stored
• entire set of DID document response data
• Merkle Proof
• block hash signed be the validator nodes

With these proofs in place a verifier client can check the DID document payload data by verifying the Merkle proof and the signed block hashes. This means that the verifier can proof that the other random chosen validators would have returned the same DID document response.

Potential further advancements of the solution

• DID data are stretching across multiple blocks of blockchain. This means we need to process multiple blockchains and Merkle proofs as outlined above.
• Introduction of a nounce created of the verifier that is blended with the block hashes signed by the validators.
• Each universal resolver has an agency that stores life-cycle credentials including credentials about the validation of the resolver implementation. Any verifier can check the validation credentials about the uni resolver implementation and decide if he or she can trust the uni resolver. A credential can also be a white listing credential of the cross-validation network.
• Staking mechanisms for slashing the stake of an actor that offers a universal resolver implementation in case it delivers a manipulated result (see also the slock.it implementation).
• Whitelist and blacklist registries

Reference
slock.it incubed lightweight IoT client for reading from remote ETH or BTC nodes.

[rknobloch]

The BTC capability of the Incubed clients is in development, it is not yet released.
This concept may be usable for all centralized points in decentraliced blockchain environments.

[peacekeeper]

@cstoecker thanks for your thoughts on this!

Some comments:

• The DIF "Universal Resolver" is just one implementation of a DID resolver, there are also other implementations of DID resolvers. The one publicly hosted instance at https://uniresolver.io/ has a warning icon which basically says that you should not trust it :)
• Keep in mind that DID resolvers are not necessarily remotely hosted services, they could also just be local libraries (we've been using the loosely defined terms "local resolver" and "remote resolver").
• Also keep in mind that not every DID method is blockchain based, so some of your assumptions only work for certain DID methods.
• Regarding remote resolvers, how to trust their responses has been a long-standing topic which we have discussed a number of times during the DID Resolution meetings and in other places. For example, see the following links:
  • Section DID Resolution Architectures in the DID Resolution Spec.
  • Issue 'remote' vs 'local' DID Resolvers did-resolution#28.
  • DID Resolution meeting recording and slides from 2019-11-14.
  • The new PR Add initial content for DID Resolution. #247 on the DID Core spec, which proposes "DID document metadata" and "DID resolution metadata", which can each contain various proofs, including the ones you are describing, or Sovrin state proofs, or a Bitcoin "Satoshi audit trail", etc.!

Perhaps you have time to join today's DID Resolution meeting?

[SmithSamuelM]

In KERI an interaction or rotation event payload may include a list of seals (anchors in KERI terminology) that are digests (hashes) of data stored off-log (off chain). A digest may be for the data item itself or the hash tree root hash. No information about the data is leaked other than its hash. All a client (end user) needs to do is find the hash in a KERI interaction event payload to establish control authority at the time the hash was sealed (anchored) to the keri log. The set of events up to that location in the log then become a verifiable proof. A resolver merely needs to provide the identifier prefix and some reference to where a log may be found along with the hash. For uniqueness the validator confirms consistency (non-duplicity) of the log within its watcher network. Because only the controller of the identifier may create a verifiable (signatures) log the only guarantee that the watcher network need provide is consistency or the absence of duplicity on the behalf of the controller. This approach generalizes to any storage medium for the logs. These may include a blockchain ledger. This generalizes the incubed approach and makes proving blockchain/ledger agnostic.

[OR13]

This is imo not a WG / Spec issue... its a trust in software systems issue...

I would support some minor informative language about encouraging implementers to run all infrastructure needed to perform resolution themselves.

[peacekeeper]

On today's DID WG call @talltree suggested that we can cover this topic in the "Security Considerations" section of DID Core, and then point to DID Resolution for additional considerations.

[SmithSamuelM]

@OR13 The issue is that its a security problem if its merely a “trust in software systems issue”. If we embue the spec with the property of what I call “end-verifiably” then it stops being a “trust in software systems issue”. If you think about it a verifiable credential is not truly verifiable if its trust basis includes “trust in software systems issues”. Is a somewhat verifiable credential. On the other hand if DID:docs are end verifiable via a veritable proof to their root-of-trust then a VC becomes verifiable all the way down.

[OR13]

I'm not sure that any data model or protocol are verifiable in absence of a formal systems like coq, agda, TLA+, or proverif... every abstract cryptographic protocol, when made concrete suffers from the same issue... see also ken thompson's reflections on trusting trust... but i think this is mostly philosophical at this point, there should informative statements somewhere that can help address this... i'm not attached to where they are.

@SmithSamuelM if there is language you would like to propose to address this issue, please open a PR, I'm happy to review.

[SmithSamuelM]

@OR13 I am not talking about verifying "what" was conveyed by the VC but verifying that the correct "who" conveyed it. So it does not require a formal data verification system per-se. We are just talking about verifying the establishment of control over an identifier. The concept is straight forward. In the simple case, a given signature on some some statement created with a private key is verifiable with a given public key. The who in this case is the controller of the private key purported as authoritative for the identifier purported to be the signer. The data model consideration is merely answering the question, who are the signers (key-pairs/identifers) and how do we verify them? Not any other data. Verifying that a given key-pair is indeed the authoritative key pair for the identifier to which the statement is attributing as the signer is the task nothing more. Not sure why this is not crystal clear.

So in the context of this issue:

1. When the purported key-pair is provided in a DID:Doc by a DID resolver then either:

A- The resolver provides an end-verifiable proof of the authoritative nature of that key-pair
or
B- the end user must trust that DID:DOC provided by the DID resolver was indeed authoritative, from which the end user may extract the authoritative key-pair.

2. If the only mechanism we have to establish the authoritative key-pair is trust in the resolver's software systems, i.e. that we trust that the method code run by the resolver will produce an authoritative DID:doc, then we have made our system vulnerable to the same class of attacks as the current DNS/CA system. These are various forms of DNS hijacking attacks that hijack resolvers and produce verifiable certificates but with non-authoritative key-pairs. A did:doc that self asserts the authoritative key:pair for the attached signature is not secure! There must be some other mechanism that proves the DID:DOC itself is authoritative. This is the intrinsic vulnerability of X509 certificates. Its the assertion of the authoritative key-pair that is the problem. So we can either require a simple proof of the authoritative key-pair or require the more complex proof that a did:doc is authoritative from which we can extract the authoritative key pair. I vote for the former. In the former case the did:doc must merely be consistent with the proof but the proof is not dependent on the did:doc itself.

To elaborate if we require DID resolution to provide an end-verifiable proof of the authoritative key-pair then we do not have to trust the DID resolver software systems at all. In this latter case, the only attack against a DID resolver is a deletion attack that removes any knowledge of the DID or DID method from the resolver and that is simply mitigated by redundancy of DID resolvers.

IMHO it would be most unfortunate if instead of fixing the security problems of the existing DNS/CA system we instead multiplied them. As it currently stands absent proofs of control authority, every method via its method code becomes the method authority which is reliant on vulnerable software systems (e.g. DID resolver executed method code) as its root-of-trust instead of a cryptographically end-verifiable root-of-trust. The KERI white paper explains this in some detail.

IMHO there are two primary roots-of-trust that may provide such an end-verifiable proof.

1. A BFT totally ordered distributed consensus ledger
2. a self-certifying identifier.

In the former case a proof could be of in the form of ledger state proof of the current authoritative key pair. In the latter case a key event receipt log (hash chained data structure) of key events (KERI KERL) that establish the current authoritative key pair starting from the originating self-certifying inception event. As soon as you move outside either of these two mechanisms, it gets really complicated.

As a final note KERI makes a ledger unnecessary via ambient duplicity detection or a ledger provides at most a secondary (replaceable) root-of-trust. This enables portability at the cost of ambient duplicity detection. In either case the KERI proof is a KERL. All that changes is where the KERL is stored.

[SmithSamuelM]

@cstoecker @OR13 With respect to this specific proposal, the proposed mechanism is a mechanism for a concrete verification against a block chain. As such it is not appropriate as a normative part of the specification. My comments are addressing what I do consider normative, that is, each DID method specifies an end-verifiable proof mechanism for the authoritative key-pairs that sign the given resolved DID:Doc. This proposal could be used to implement one of those proof mechanisms.

[msporny]

From @talltree and @OR13 during a WG call: This statement belongs in the implementation guide. This is a security consideration, not a privacy consideration. There might already be a statement here... but most of this belongs in implementation guide.

[peacekeeper]

The DID Resolution spec already has some content about local vs. remote bindings, verifiable vs. unverifiable reads operations, proofs that can be added to metadata, etc. I think these topics should be further expanded in the DID Resolution spec.

[peacekeeper]

@cstoecker Since you raised this issue, would you agree that this could go into a different document, i.e. either the DID Resolution spec in the CCG, or the Implementation Guide in the WG. If so, can we close the issue here and follow up in the other repos?

Or do you have a suggestion what we could add to DID Core to address this?

[msporny]

There seems to be agreement that this issue shouldn't be addressed in the DID Core spec and should instead be addressed in the implementation guide or the DID Resolution specification. Marking this as pending close. This issue will be closed in 7 days unless there are objections.

[brentzundel]

No comments since marked pending close, closing