From f7a397dc90c87b64707a80471a886ff1d97897bd Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Mon, 23 Nov 2020 12:14:22 -0500 Subject: [PATCH] add proposal for Single SSSS --- proposals/xxxx-single-ssss.md | 55 +++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 proposals/xxxx-single-ssss.md diff --git a/proposals/xxxx-single-ssss.md b/proposals/xxxx-single-ssss.md new file mode 100644 index 00000000..7a920d1a --- /dev/null +++ b/proposals/xxxx-single-ssss.md @@ -0,0 +1,55 @@ +# MSCxxxx: Single SSSS + +[Secure Secret Storage and +Sharing](https://github.com/matrix-org/matrix-doc/pull/1946) (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. + +## 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 not 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.