MSC2399: Reporting that decryption keys are withheld

[uhoreg]

Rendered

[ara4n]

this is looking very good to me, fwiw

[turt2live]

seems sane

[uhoreg]

This has been implemented and seems to be working.

[uhoreg]

@mscbot fcp merge

[mscbot]

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

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

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.

[cloudyfuel]

I think I have a better solution.

Instead of Bob being responsible for telling Alice that Alice's device doesn't send keys, the Alice's device - the root of the problem - should be responsible for this. Bob should be shown a generic status event like 'Alice didn't send you the key, this may be because she didn't verify you, blacklisted you' or no message at all on the corresponding device.

Why leak verification status, blacklisting status or if the user lost their key to random third parties the user most likely doesn't wish to communicate with? Why rely on an entity completely out of your control to tell you there's something wrong with your device? Why hide the fact that someone is probing me for keys? Seems intuitive that I should know if someone is contacting me instead of them knowing that and additionally a bunch of metadata about my setup.

Separately from this, if there's a real need for communicating that to random parties, the device could communicate that. But that makes sense only for communicating errors and only when this can point the sender to fixing the problem (rather than saying: oh there's an error, but you can't do anything about it lol).

Edit: AFAIU the key withheld events are also unencrypted, so they leak metadata to the server too. This is at least as bad and can be mitigate similarly by simply informing the user about these problems rather than needlessly sending that info to whoever via the server.

[uhoreg]

@cloudyfuel I'm confused by what you're saying.

Instead of Bob being responsible for telling Alice that Alice's device doesn't send keys, the Alice's device - the root of the problem - should be responsible for this.

This is what the proposal is. The Alice's device is sending a message saying that it is purposely not sending keys to Bob.

Bob should be shown a generic status event like 'Alice didn't send you the key, this may be because she didn't verify you, blacklisted you' or no message at all on the corresponding device.

This is what is done without this proposal. The generic message is "The sender's device has not sent us the keys for this message." in Riot Web.

Why leak verification status, blacklisting status or if the user lost their key to random third parties the user most likely doesn't wish to communicate with?

It's not leaked to random third parties. It's sent as a to-device message, so only the users and their homeserver admins can see it. Also, "lost their key"?

Why rely on an entity completely out of your control to tell you there's something wrong with your device?

That is not what the proposal it doing.

Why hide the fact that someone is probing me for keys? Seems intuitive that I should know if someone is contacting me instead of them knowing that and additionally a bunch of metadata about my setup.

Huh? I don't understand what this has to do with the proposal.

But that makes sense only for communicating errors and only when this can point the sender to fixing the problem (rather than saying: oh there's an error, but you can't do anything about it lol).

In practice, it has helped debug some cases of unintentional unable-to-decrypt errors by pointing to the exact cause of the issue (e.g. the sender had turned on the option to only send to verified devices without meaning to). It also indicates to the user that they should not expect to be able to read the message, so they don't have to wonder if they'll ever be able to.

Edit: AFAIU the key withheld events are also unencrypted, so they leak metadata to the server too.

The current implementation in Riot sends them unencrypted, but they could be encrypted if needed. But I don't really see it as particularly sensitive information. The messages are optional in any event, so if you're worried about leaking the data, you could simply not send it.

[uhoreg]

Added a section about key sharing.

[richvdh]

I'd have gone with something slightly more generic here, since the problem is a failure to create a peer to peer encrypted channel rather than anything specific to olm (one day people might use another mechanism). Not a strong opinion though.

[mscbot]

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

[mscbot]

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

[turt2live]

Spec PR: #2826

[turt2live]

Merged 🎉