Breach of DID-generating private key

[Oskar-van-Deventer]

I believe that we need to discuss explicitly the case where Alice’s private key to generate her did:peer with Bob got lost or stolen.
o Should Alice notify Bob, once she becomes aware of such breach?
o Should Bob notify Alice, if another person tries to establish a pairwise DID relationship with Bob, using Alice’s did:peer?
o Should Bob accept or reject the new pairwise DID relationship?
Note that this case would not exist in my interpretation of pairwise DID. So different interpretations would result in different implementations.

Oskar
TNO - Techruption

[dhh1128]

I think the enhancement you've proposed (that the initial key value should be rotated quickly) would address this weakness. However, it is not needed if the DID value is based on a hash of the DID Doc instead of on the public key. So I am inclined to hold this issue open until we decide if we are going to update the method such that it hashes the whole DID Doc--but then close it if the answer is yes. Do you agree, or do you think we'd be losing something?

[Oskar-van-Deventer]

Let us keep the issue open for further discussion.

• The "DID-value-based-on-DID-Doc-hash" method would likely eliminate the need for the quick initial rotation. I'd like to have at least Kyle's opinion on this as well, as I am not yet fully comprehending the implications of that method.
• We definitely need to specify a protocol procedure somewhere about what to do if a Peer-DID-based microledger appears to be forked.
  Option a) Specify in Peer DID itself.
  Option b) Specify in DID Com, as the forking issue may apply to any DID.
  Option c) Do both, as the procedure for Peer DID may be different than for anywise DIDs.

To be further discussed ...

[kdenhartog]

One of the reasons for rotating the origin key is to reduce traceability of communicating parties. Specifically if Alice initiates a pairwise DID connection using the connection protocol, she has to provide this to Bob in plaintext. By rotating the key, I believe (I still need to look into a traffic analysis model of this more) it reduces the correlation between Alice and Bob. However, what I'm not certain of is if this actually makes a difference because the key is left in plaintext whenever bob sends a message to Alice with the current DIDCom implementation.

With MLS, there's a long term identity key that I believe is used for key derivation for each ratchet (one ratchet per message) and I'd prefer to key that kept secret if not needing to be revealed. Let's leave this open, so that I can add notes as I reread and reinterpret the MLS spec.

Can you explain what you mean by a microledger being forked? I'm not able to think of a use case where this would happen.

[Oskar-van-Deventer]

Can you explain what you mean by a microledger being forked? I'm not able to think of a use case where this would happen.

It would happen only in error situations or security breaches.

• Alice recovers an old back-up of its DIDCom agents and performs a Peer-DID DID Document roll-over. However, such roll-over had already happened in the past, resulting in a fork of the microledger.
• One of Alice's agents performs a DID Document roll-over while the other user agent is off-line. Later, Alice's other user agent performs a similar DID Document roll-over, again resulting in a fork.
• Mallory obtains a copy of Alice's keys and performs a DID Document roll-over. Later, Alice's user agent makes a similar roll-over, gain resulting in a fork.

Whenever Bob discovers that Alice's microledger has been forked, he should assume error or malice, consider Alice's Peer DID breached, warn all involved, discontinue using Alice's DID, and possibly establish a new DID pair with Alice.

[dhh1128]

I agree with Oskar's summary. I think we should distinguish between errors and malice, if possible. I don't know if it *is* possible, but it would be nice not to assume malice and take draconian action if an innocent error causes the problem. We need to think about that a bit and see what's practical.

…

On Mon, May 20, 2019 at 3:22 AM Oskar van Deventer ***@***.***> wrote: Can you explain what you mean by a microledger being forked? I'm not able to think of a use case where this would happen. It would happen only in error situations or security breaches. - Alice recovers an old back-up of its DIDCom agents and performs a Peer-DID DID Document roll-over. However, such roll-over had already happened in the past, resulting in a fork of the microledger. - One of Alice's agents performs a DID Document roll-over while the other user agent is off-line. Later, Alice's other user agent performs a similar DID Document roll-over, again resulting in a fork. - Mallory obtains a copy of Alice's keys and performs a DID Document roll-over. Later, Alice's user agent makes a similar roll-over, gain resulting in a fork. Whenever Bob discovers that Alice's microledger has been forked, he should assume error or malice, consider Alice's Peer DID breached, warn all involved, discontinue using Alice's DID, and possibly establish a new DID pair with Alice. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19?email_source=notifications&email_token=AAQ3JCDV6CN3B2SGWWVRL5LPWJUWXA5CNFSM4HFRAERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVYGZ2I#issuecomment-493907177>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQ3JCB2SD5F4RQQ5VTNG3LPWJUWXANCNFSM4HFRAERA> .

[Oskar-van-Deventer]

distinguish between errors and malice, if possible.

That would indeed be useful IF possible.

take draconian action if an innocent error causes the problem.

I do not consider those two errors "innocent". Moreover, there are different mental models of the value of a Peer DID.

1. A Peer DID is a high-value item, and decommissioning one is draconian. We need proper recovery mechanisms for a party to recover its Peer DID, even if that means that there exist forked branches of it.
2. A Peer DID is a cheap-to-generate item. If it ever gets compromised by error or malice, one just abandons it and re-establish the established pairwise or n-wise relationship with a new Peer DID.

Obviously, my mental model is the second one.

Food for thought ...

[dhh1128]

Of course the second model is correct (peer DIDs can be thrown away and replaced easily). That's not the issue.

The issue I'm concerned about (perhaps unnecessarily?) is that it might be relatively common for Alice to lose her phone for a couple days in the cushions of her couch, during which time the peer DID that she uses with Bob could evolve on her tablet. When she finds her phone again and turns it back on, we hope that the phone will find out about the evolution in a predictable way--but I don't think we can guarantee this. I can imagine that Alice will want to rotate keys on her phone as soon as she finds it again, in case something bad happened to it while it was out of her custody--and that the rotation might happen before sync has occurred. I think the result might be forks that really are innocent.

[dhh1128]

I believe the shift to frame peer DIDs in terms of KERI will largely eliminate this issue; KERI's inception key is combined with a pre-rotation strategy that anticipates such a risk. However, I've created an issue in the new repo home for this spec, so we can track it to closure. decentralized-identity/peer-did-method-spec#16