Add security and privacy considerations

[jesusdiazvico]

On the topic of ProtocolVersionUpdateOperations and security considerations: should we comment something on how to mitigate the situation in which the SYSTEM_UDPATE_DID gets compromised or lost? Currently, I can only think of two approaches to mitigate that:

1. We manually apply some thresholding technique to the SYSTEM_UDPATE_DID (probably more secure, but a UX nightmare).
2. We add multiple public keys into the SYSTEM_UPDATE_DID, such that any of the corresponding private keys can run a ProtocolVersionUpdateOperation. Then, each of those private keys is securely stored in a separate location. (This option probably less secure if all those keys can be derived from the same mnemonic, but much more usable than the other option).

In any case, the private key material/mnemonic/whatever should be stored offline.

What do you think?

[EzequielPostan]

On the topic of ProtocolVersionUpdateOperations and security considerations: should we comment something on how to mitigate the situation in which the SYSTEM_UDPATE_DID gets compromised or lost?

I am not sure if we need to go to this level of detail. Having many keys help for the "lost key" case, but makes it less secure for the "compromised key" case (because now there are more potential keys to securely store)

If a key is lost, we may be able to communicate all operators to change (or even delete) the SYSTEM_UDPATE_DID from their config files. But this may be trickier than what it sounds after some updates have actually occur. For compromised keys I can only think about having an m-out-of-n multisig setting. With a 2-out-of-3 you have room for one lost/compromised key, but you now need to manage 3 keys instead of 1. I am not aware of an ideal solution.

[jesusdiazvico]

Yep, an m-out-of-n type of solution (where there are n SYSTEM_UPDATE_DIDs and m need to agree on an update, or similar -- this is in line with the governance topic) would be the ideal. But that would also add a lot of complexity.

Telling the operators to manually change the DID does sound very tricky (and, as a user, I would look at such event with a lot of mistrust.

We can do that "thresholding" internally, though. And divide the mnemonic of the SYSTEM_UPDATE_DID in n chunks, so that we need at least m in order to recompute the DID. In that regard, maybe we can add a generic sentence like:

The owner of SYSTEM_UPDATE_DID should take the appropriate measures to protect such DID. These measures can include applying threshold techniques.