[WIP] MSC2697: Device dehydration

[uhoreg]

Rendered

related to element-hq/element-web#3825

implementation: synapse: matrix-org/synapse#8380, matrix-js-sdk: matrix-org/matrix-js-sdk#1436

[clokep]

What happens in the case of them providing restore_device and device_id? Is device ID ignored?

[uhoreg]

I'll clarify this in the text, but basically, if they specify a device_id, then it will be used in the event that the dehydrated device is not used.

[clokep]

Looking at this again with fresh eyes (and some conversations with @richvdh) there's a couple of questions we have:

• Why is this being put into the (already complicated) login flow? An alternative might be to do a normal login and then request restoring a device. There's something about a device ID + access token pair being immutable, but we weren't sure where that logic came from (or if it is necessary). This could help avoid having to create a new dehydrated_token since the user would have a standard access token.
• What is the failure mode if a client cannot rehydrate the device (I think they send rehydrate to false), but either way I think they get logged in? If so, it seems like it would be simpler for the flow to be:
  • Client logs in normally.
  • Client requests the dehydrated device.
  • If client can rehydrate the device it does so, and tells the server it will be using it. Server responds with an ack saying it is OK to use it. (And maybe has to do with something with device IDs on the backend, but that seems quite implementation specific.)

[uhoreg]

If so, it seems like it would be simpler for the flow to be:

• Client logs in normally.
• Client requests the dehydrated device.
• If client can rehydrate the device it does so, and tells the server it will be using it. Server responds with an ack saying it is OK to use it. (And maybe has to do with something with device IDs on the backend, but that seems quite implementation specific.)

I think the main issue is that this would involve changing the device ID in the client, and we don't have anything that does that yet, and I don't know what implications that could have. One possible issue is if the client has started a /sync, then what happens when the device ID changes? Will it suddenly return the to-device messages from the new device, or will it wait until the next /sync call?

[clokep]

One possible issue is if the client has started a /sync, then what happens when the device ID changes? Will it suddenly return the to-device messages from the new device, or will it wait until the next /sync call?

I think it would be reasonable for the client to know not to call any other APIs until the dehydrated device API call is done (since the client will know whether or not it is going to make that call).

[ara4n]

can we put the MSC label on this so it's easier to find (even though it's still WIP?)

[opusforlife2]

This couldn't come fast enough. I have to sheepishly ask people to resend messages each time I log in and see "Unable to decrypt".

[clokep]

There's something about a device ID + access token pair being immutable, but we weren't sure where that logic came from (or if it is necessary).

The specification does say something about this:

Client devices are closely related to access tokens. Matrix servers should record which device each access token is assigned to, so that subsequent requests can be handled correctly.

By default, the Login and Registration processes auto-generate a new device_id. A client is also free to generate its own device_id or, provided the user remains the same, reuse a device: in either case the client should pass the device_id in the request body. If the client sets the device_id, the server will invalidate any access token previously assigned to that device. There is therefore at most one active access token assigned to each device at any one time.

My interpretation of this is that we need to ensure that mapping between device ID <---> access token is unique, but there shouldn't be an issue with changing the device ID by calling an API. (In fact this is a thing that is already described in the paragraph above -- the client ID provided by the client can be ignored and the server can choose to create a new device ID.)

From the above, my inclination would be to disconnect this from explicitly being part of the login flow, although include some information of "generally device rehydration will happen directly after login". I might be over-simplifying something somewhere else in the specification though!

[MayeulC]

The unusual name caught my attention. I personally find that, while that name is cute and might be fine as a codename for now, it is absolutely not obvious from the outside, and one has to read the MSC to understand what that means.

This simply sounds like "sending megolm keys to key backup" to me, or "key backup as a device" :)

As a consequence of this, what are the security implications? How could I verify someone's key backup (dehydrated device)? Have one of their device cross-sign it? What prevents someone who takes over the account from creating a new key backup and/or dehydrated device, then extracting the keys from it?

I might have misunderstood the MSC, my apologies if that's the case.

Rather than uploading a dehydrated device to the server, we could instead have the sender resend the megolm session in the case where a user had no active devices at the time that a message was sent. However this does not solve the issue for users who happen to never be online at the same time. But this could be done in addition to the solution proposed here.

Must this be done in real time? Couldn't it be done asynchronously?

[uhoreg]

As a consequence of this, what are the security implications? How could I verify someone's key backup (dehydrated device)? Have one of their device cross-sign it?

Yes, cross-signing would be the normal way to establish trust. One advantage to using a dehydrated device rather than some other mechanism is that the way that we treat normal devices carries over to the dehydrated devices.

What prevents someone who takes over the account from creating a new key backup and/or dehydrated device, then extracting the keys from it?

If they've taken over the account, then they can just create a normal device, so this doesn't give them anything else.

Must this be done in real time? Couldn't it be done asynchronously?

It can be done asynchronously as usual olm messages are sent asynchronously. However it relies on both users having a device that is logged in at the same time. There are instances where Alice and Bob only log in for short periods of time and then log out immediately. (The MSC should probably say "...this does not solve the issue for users who never happen to have logged-in devices at the same time.")

[turt2live]

is it possible to break out full examples on this? Creating types for this isn't the easiest thing at the moment (hard to see what it replies with):

export interface IDehydratedDevice {
    device_id: string;
    device_data: {
        algorithm: string;

        // TODO: Fill in from MSC2697
        // https://github.com/matrix-org/matrix-doc/pull/2697
        [key: string]: any;
    }
}

[richvdh]

It's not ideal that we're tying this to a particular implementation's format, not least because, as noted over at matrix-org/olm#53, it's not entirely obvious that libolm's pickles are the most sensible format.

[uhoreg]

Indeed. Vodozemac is also defining its own JSON-based pickle format.

libolm's pickle format is very much tied to some implementation details (e.g. otk IDs being a counter), so may not be suitable for other implementations. On the other hand, a more generic format may not be usable by libolm. We may end up with a situation where we'll end up with multiple pickle formats for dehydration (e.g. m.dehydration.v1.olm.libolm_pickle, m.dehydration.v1.olm.vodozemac_pickle), and you'll only be able to rehydrate if your implementation supports that format. Which is ... not ideal, but may be unavoidable unless we also want to end up dictating certain things about implementation details.

[DMRobertson]

Presumably:

• device_data andalgorithm are mandatory
• other fields can be freely included in device_data
• initial device display name is optional (mirroring /login)?

[DMRobertson]

xref matrix-org/synapse#14052

[uhoreg]

Yes, that's correct

[Julian-Dumitrascu]

Where is device dehydration defined?
I don't know what it is and Google Search hasn't helped.
I'd like to decide whether to use this feature.

[BillCarsonFr]

There is I think some side effects to expect with verifications and device list management.
A dehydrated device will appear as a regular device in keys/query right?

1. Should we display them as a regular device in the device list manager? Wouldn't it look suspicious for user with only one login to see 2 devices?

2. Also what happen when you request a verification to such devices? Does it impacts the self verification process (where we check for existing devices?

[uhoreg]

The client could tell which device is the dehydrated device by calling GET /dehydrated_device and comparing device IDs. Alternatively, (and maybe better) we could make the server throw a flag in the unsigned portion of the device key object, maybe a "dehydrated": true.

Either way, it would be up to the client to handle the issues that you listed, e.g. by displaying them differently from regular devices, omitting them from verifications, etc.

[opusforlife2]

Has this not been superseded by #3814?

[uhoreg]

Has this not been superseded by #3814?

The plan is to do 3814 instead of this, but 3814 hasn't been properly tested yet. (Famedly has an implementation of something similar, but slightly different from what is in the MSC.) Once 3814 is implemented and reasonably tested, this will probably be closed.

[richvdh]

@uhoreg should we close this, since we're now reasonably committed to MSC3814?

[uhoreg]

Closed in favour of #3814