archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

wip

Browse Source
rav/proposal/encrypted_history_sharing
Richard van der Hoff 8 months ago
parent ed3691cb65
commit e1d65a3c37
1 changed files with 92 additions and 47 deletions
Show Stats Download Patch File Download Diff File

139
proposals/4268-encrypted-history-sharing.md
Unescape Escape View File

@ -1,56 +1,101 @@
# MSC0000: Template for new MSCs # MSC4268: Sharing room keys for past messages
*Note: Text written in italics represents notes about the section or proposal process. This document In Matrix, rooms can be configured via the
serves as an example of what a proposal could look like (in this case, a proposal to have a template) [`m.room.history_visibility`](https://spec.matrix.org/v1.14/client-server-api/#room-history-visibility)
and should be used where possible.* state event such that previously-sent messages can be visible to users that
join the room. However, this is ineffective in encrypted rooms, where new
joiners will lack the keys necessary to decrypt historical messages.
*In this first section, be sure to cover your problem and a broad overview of the solution. Covering This proposal defines a mechanism by which existing room members can share the
related details, such as the expected impact, can also be a good idea. The example in this document decryption keys with new members, for example when inviting them, thus giving
says that we're missing a template and that things are confusing and goes on to say the solution is the new members access to historical messages.
a template. There's no major expected impact in this proposal, so it doesn't list one. If your proposal
was more invasive (such as proposing a change to how servers discover each other) then that would be
a good thing to list here.*
*If you're having troubles coming up with a description, a good question to ask is "how
does this proposal improve Matrix?" - the answer could reveal a small impact, and that is okay.*
There can never be enough templates in the world, and MSCs shouldn't be any different. The level
of detail expected of proposals can be unclear - this is what this example proposal (which doubles
as a template itself) aims to resolve.
A previous propsal,
[MSC3061](https://github.com/matrix-org/matrix-spec-proposals/pull/3061) aimed
to solve a similar problem; however, the mechanism used did not scale well. In
addition, the implementation in `matrix-js-sdk` was subject to a [security
vulnerability](https://matrix.org/blog/2024/10/security-disclosure-matrix-js-sdk-and-matrix-react-sdk/)
which this proposal addresses.
## Proposal ## Proposal
*Here is where you'll reinforce your position from the introduction in more detail, as well as cover ### `shared_history` property in `m.room_key` events
the technical points of your proposal. Including rationale for your proposed solution and detailing
why parts are important helps reviewers understand the problem at hand. Not including enough detail Suppose Alice and Bob are participating in an encrypted room, and Bob now
can result in people guessing, leading to confusing arguments in the comments section. The example wishes to invite Charlie to join the chat. If the [history
here covers why templates are important again, giving a stronger argument as to why we should have visibility](https://spec.matrix.org/v1.14/client-server-api/#room-history-visibility)
a template. Afterwards, it goes on to cover the specifics of what the template could look like.* settings allow, Bob can share the message decryption keys for previously sent
messages with Charlie. However, it is dangerous for Bob to take the server's
Having a default template that everyone can use is important. Without a template, proposals would be word for the history visibility setting: a malicious server admin collaborating
all over the place and the minimum amount of detail may be left out. Introducing a template to the with Charlie could tell Bob that the history visibility was open when in fact
proposal process helps ensure that some amount of consistency is present across multiple proposals, it was restricted. In addition, the history visibility in a given room may have
even if each author decides to abandon the template. been changed over time and it can be difficult for clients to estalish which
setting was in force for a particular Megolm session.
The default template should be a markdown document because the MSC process requires authors to write
a proposal in markdown. Using other formats wouldn't make much sense because that would prevent authors To counter this, we add a `shared_history` property to `m.room_key` messages,
from copy/pasting the template. indicating that the creator of that Megolm session understands and agrees that
the session keys may be shared with newly-invited users in future. For example:
The template should have the following sections:
```json
* **Introduction** - This should cover the primary problem and broad description of the solution. {
* **Proposal** - The gory details of the proposal. "type": "m.room_key",
* **Potential issues** - This is where problems with the proposal would be listed, such as changes "content": {
that are not backwards compatible. "algorithm": "m.megolm.v1.aes-sha2",
* **Alternatives** - This section lists alternative solutions to the same "room_id": "!room_id",
problem which have been considered and dismsissed. "session_id": "session_id",
* **Security considerations** - Discussion of what steps were taken to avoid security issues in the "session_key": "session_key",
future and any potential risks in the proposal. "shared_history": true
}
Furthermore, the template should not be required to be followed. However it is strongly recommended to }
maintain some sense of consistency between proposals. ```
In other words: when Alice wants to send a message in the room she shares with
Bob, she first checks the `history_visibility`. If it is `shared` or
`world_readable`, then when she sends the Megolm keys to Bob, she sets
`shared_history` to `true`.
Clients SHOULD show a visual indication to users that their encrypted messages
may be shared with future room members in this way.
If the history visibility changes in a way that would affect the
`shared_history` flag (i.e., it changes from `joined` or `invited` to `shared`
or `world_readable`, or vice versa), then clients MUST rotate their outbound
megolm session before sending more messages.
In addition, a `shared_history` property is added to the [`BackedUpSessionData`
type](https://spec.matrix.org/v1.14/client-server-api/#definition-backedupsessiondata)
in key backups (that is, the plaintext object that gets encrypted into the
`session_data` field) and the [`ExportedSessionData`
type](https://spec.matrix.org/v1.14/client-server-api/#definition-exportedsessiondata). In
both cases, the new property is set to `true` if the session was shared with us
with `shared_history: true`, and `false` otherwise.
For example:
```json
{
"algorithm": "m.megolm.v1.aes-sha2",
"forwarding_curve25519_key_chain": [
"hPQNcabIABgGnx3/ACv/jmMmiQHoeFfuLB17tzWp6Hw"
],
"sender_claimed_keys": {
"ed25519": "aj40p+aw64yPIdsxoog8jhPu9i7l7NcFRecuOQblE3Y"
},
"sender_key": "RF3s+E7RkTQTGF2d8Deol0FkQvgII2aJDf3/Jp5mxVU",
"session_key": "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8Llf...",
"shared_history": true
}
```
In all cases, an absent or non-boolean `shared_history` property is treated the same as
`shared_history: false`.
### Key bundle format
TODO
### To-device message format
## Potential issues ## Potential issues

Write Preview
Loading…
Cancel
Save