Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] MSC3814: Dehydrated devices with SSSS #3814

Draft
wants to merge 25 commits into
base: main
Choose a base branch
from
+390 −0
Draft

[WIP] MSC3814: Dehydrated devices with SSSS #3814

Changes from 1 commit
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
80243a4
Initial proposal for dehydrated devices with SSSS
uhoreg May 12, 2022
ed2c5eb
use MSC number
uhoreg May 12, 2022
703281e
wording improvements and clarifications
uhoreg Sep 5, 2022
0a149c5
Uploading a dehydrated device now uploads the public keys as well
poljar Aug 9, 2023
a4e87a6
Make the next_batch token non-optional in the response
poljar Aug 9, 2023
3827bc0
Let's not delete to-device events when a client receives them
poljar Aug 9, 2023
12acd43
Introduce the DELETE endpoint
poljar Aug 9, 2023
f756db3
Attempt to define the dehydration format
poljar Aug 10, 2023
6223db4
Don't use operatorname, try to unwedge the Latex
poljar Aug 10, 2023
e3c9ac8
More Latex tweaks
poljar Aug 10, 2023
7f24f0d
Remove the bytes unit from every single row, put it in the header
poljar Sep 5, 2023
f85c18d
Attempt to fix the math rendering
poljar Sep 5, 2023
4954c27
Align the table headers for the pickle format
poljar Sep 5, 2023
087154a
Fix JSON example
uhoreg Feb 8, 2024
e7c8266
link to fallback key spec
uhoreg Feb 12, 2024
cf5ae99
add dehydrated flag
uhoreg Feb 23, 2024
d751d33
Apply suggestions from code review
uhoreg Nov 19, 2024
11149e4
define new format and add more security notes
uhoreg Nov 22, 2024
1500897
suggest dropping to-device messages sent from a dehydrated device
uhoreg Dec 16, 2024
5742c52
link to the base64 format that we use
uhoreg Dec 16, 2024
a58288a
we need the ed25519 key after all
uhoreg Dec 16, 2024
21a3d67
add note about URL-safe base64
uhoreg Dec 16, 2024
6be9078
update dehydration format
uhoreg Dec 28, 2024
ec17903
fix typo
uhoreg Jan 10, 2025
9d6d059
fix typo
uhoreg Jan 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
suggest dropping to-device messages sent from a dehydrated device
  • Loading branch information
@uhoreg
uhoreg committed Dec 16, 2024
commit 1500897eab2eb09e620b619eca2a7c19077cb050
4 changes: 3 additions & 1 deletion proposals/3814-dehydrated-devices-with-ssss.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,9 @@ structure as for the [`/keys/upload`] request.
We add a new optional property to the device keys: `dehydrated`, which is set to
`true` for dehydrated devices. Defaults to `false`. Clients that support
dehydrated devices *must not* encrypt to devices marked as being a dehydrated
device if they are not cross-signed. Clients can use also this flag to for
device if they are not cross-signed. Clients should also drop any to-device
messages from a device marked as being a dehydrated device, since dehydrated
device should not be sending messages. Clients can use also this flag to for
uhoreg marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

@andybalaam andybalaam Jan 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case of encrypted messages, we can identify the sending device using the sender key, or MSC4147 device info. 2 questions:

  1. What about unencrypted messages? Even if the event content contains a device id, we can't trust that a malicious homeserver didn't just fake it. Should we just allow all unencrypted to-device messages?
  2. What if the sender key is not found, maybe because the device is logged out (and there is no MSC4147 device info)? Should we assume the device is not dehydrated and process it as normal? This gives a way to work around the messages being dropped, but it's hard to see what else we can do in this case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @dkasak

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This only applies to encrypted messages, since those are the only ones that can be reliably tied to a device. We can also drop verification requests from dehydrated devices too, but I think that would be optional.
  2. This would be a best-effort thing. If we really have no idea about the device, then we would keep the message.

other purposes, such as:

- Display dehydrated devices differently from normal devices, to avoid confusing
Expand Down