MSC4147: Including device keys with Olm-encrypted events

[uhoreg]

Rendered

disclosure: I am on the Spec Core Team and employed by Element. This MSC is written as part of my work in the Crypto team at Element

---

FCP tickyboxes

[turt2live]

Implementation requirements:

• Client sending this information
• Client using this information
• Demonstration of the core problem being solved (likely covered by the above tasks)

[uhoreg]

This has been implemented in the Rust matrix-sdk-crypto crate, both sending and using. Demonstration of the problem being solved: https://youtu.be/b1jJlT2ENT8?feature=shared&t=345

[richvdh]

A few links to the implementation.

On the sender side, the field is added here.

On the receiver side, it is deserialized after decryption into a DecryptedOlmV1Event. It is then used in SenderDataFinder whose job it is to construct a SenderData which records our knowledge about the sending device for a given session.

[richvdh]

I think this is ready for FCP, so:

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Concerns:

• implementation-needs-checking label

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[turt2live]

@mscbot concern implementation-needs-checking label

(the needs-implementation label was not removed when the FCP was proposed or implementations listed, so I am assuming they have not been checked out of an abundance of caution)

[richvdh]

I've looked at the implementation, and checked that it matches the proposal to the best of my ability.

[turt2live]

@mscbot resolve implementation-needs-checking label

[dbkr]

Thanks for writing up the alternative of keeping deleted devices in the device list: this otherwise would have been my question.

[ara4n]

For the record, I am still not happy with the extreme duplication of the denormalised device data per-event, rather than keeping deleted devices around device lists until their to-device msgs have been exhausted.

On the other hand, the current behaviour amounts to a security issue, and in practice this has been already implemented and shown working in the Element clients. So I'm going to approve FCP in order that we ship the fix rapidly for everyone, and am going to pray that someday we remove the denormalisation again (perhaps around the same time as senders-as-keys).

Feels really wrong though, and it's a bad smell this didn't surface before implementation began.

[clokep]

Can you spell out the impact of this? I think it is that by now including the keys the messages will be "trusted" and logging out the device won't make the messages automatically untrusted?

[richvdh]

I think it's exactly that, though @uhoreg wrote this bit so can maybe confirm.

I don't think it's a terribly significant concern, since it didn't work very well before. I think if we want users to be able to revoke signatures on devices, we need to add explicit support for that, rather making every logout be a half-assed effort at it.

[clokep]

Fair enough about having an explicit ability for that, just trying to understand impact!

[uhoreg]

Can you spell out the impact of this? I think it is that by now including the keys the messages will be "trusted" and logging out the device won't make the messages automatically untrusted?

Yes, that's the issue.

I think that at some point, we want to have a mechanism for users to indicate that a device was compromised, and that messages from it shouldn't be trusted. But that would be a separate MSC and for now, users can probably do so manually by sending messages to rooms.

[clokep]

Is persisting info into rooms as a permanent record another alternative? Does that even make sense?

[richvdh]

Yeah, you could make room members be devices, rather than users (MLS-style); as part of that, you could embed the device keys/signatures in the state events. It's something we've considered in the past (it helps with account portability, among other things); however there are a lot of moving parts to get it right, and having to send a membership event to every room you're in every time you log in is a bit of a killer.

It would really be a radically different approach, whilst this MSC is more of an incremental improvement.

[clokep]

Thanks! Not sure if this should be included or not as an alternative.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[clokep]

Thanks for answering all my questions @richvdh -- I think this is OK as an incremental improvement, but sounds like we might need to do a bigger improvement at some point in the future.

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[andybalaam]

Is the intention to make sender_device_keys mandatory, and drop to-device messages that do not include it?

[richvdh]

That was very much not part of this MSC. It's something we could do in future, but IMHO it would need another MSC, and careful thought, since it would mean cutting off the significant part of the ecosystem which doesn't yet implement this MSC.