matrix-spec-proposals/proposals/2874-single-ssss.md

MSC2874: Single SSSS

Secure Secret Storage and Sharing (SSSS) was designed to allow the user to create multiple keys that would be able to decrypt different subsets of the secrets. However, the vast majority of users do not need this feature.

This proposal defines how clients should behave if they only wish to support a single key, by defining which key clients should use if multiple keys are present. It also makes the name field in the m.secret_storage.key.* events optional, as this field was mainly added to allow a user to select between different keys.

Proposal

If a client wants to present a simplified interface to users by not supporting multiple SSSS keys, then the client should use the default key (the key listed in the m.secret_storage.default_key account data event.) If there is no default key the client may behave as if there is no SSSS key at all. When such a client creates an SSSS key, it must mark that key as being the default key.

The name field in the m.secret_storage.key.* account data events is optional, rather than required. If a client wishes to display multiple keys to a user and a given key does not have a name field, the client may use a default name as the key's name, such as "Unnamed key", or "Default key" if the key is marked as default.

For example, when a client creates a key with ID abcdefg, it will create an m.secret_storage.key.abcdefg account data event to store information about the key. It will then mark it as the default key by setting the m.secret_storage.default_key account data to {"key": "abcdefg"}. When another client logs in after this, it will see that the default key has been set, and will know to use that key as the SSSS key.

Potential issues

If secrets are encrypted using a key that is not marked as default, a client might not decrypt the secrets, even if it would otherwise be able to.

Alternatives

Rather than solely relying on the key marked as default, a client could guess at what key to use. For example, it could look at the secrets that it needs, see what keys they are encrypted with, and if there is only one common key, then it could use that. (This is what Element currently does.) Or if there are multiple keys, it could use some sort of heuristic to pick a key. However, this approach can be error-prone, and it is better to rely on an explicit marking.

Security considerations

None

Unstable prefix

An unstable prefix is not needed for a behaviour change in choosing the key to use as there are no event/endpoint changes.

Some clients already omit the name field (notably, matrix-js-sdk unintentionally does this -- mea culpa), and this does not seem to be causing issues, so an unstable prefix seems unnecessary for this.