Pre-generate E2EE recovery keys / populate 3PIDs

[Programmierus]

Due to mandatory E2EE I have to find some solution to pregenerate keys for my users and store them somewhere in a safe place. Normally they forget passwords on a weekly basis, giving them additional "passphrase" to remember will practically block the entire enterprise :)

In the FAQ I've noticed that you are saying that even with shared_secret_auth it's impossible to submit 3PIDs (e.g. E-Mail) for the users. Is it still actual? From what I see in the Client-Server-API - it's now perfectly possible...

And if yes, what would you think about a possibility to pre-generate E2EE recovery keys?

[spantaleev]

Which Client-Server API are you looking at for adding 3pids? It does require user-interaction and the involvement of an identity server, doesn't it?

For E2EE, we should do something indeed.

What's your idea about key-handling? Pregenerate them and store them where? Do what with them?

[Programmierus]

Which Client-Server API are you looking at for adding 3pids? It does require user-interaction and the involvement of an identity server, doesn't it?

I am sorry I meant the Admin API of course. For this cause it'd be necessary to add a config option to specify the admin user_id for matrix-corporal usage.

Short PoC

PUT - /_synapse/admin/v2/users/@user:domain.com

Add 3PID (Email medium)

CURL

curl -X PUT "https://matrix/_synapse/admin/v2/users/@user:domain.com" \
    -H "Authorization: Bearer AdminToken" \
    -H "Content-Type: application/json; charset=utf-8" \
    --data-raw "$body"

Header Parameters

• Authorization should respect the following schema:

{
  "type": "string",
  "enum": [
    "Bearer AdminToken"
  ],
  "default": "Bearer AdminToken"
}

• Content-Type should respect the following schema:

{
  "type": "string",
  "enum": [
    "application/json; charset=utf-8"
  ],
  "default": "application/json; charset=utf-8"
}

Body Parameters

• body should respect the following schema:

{
  "type": "string",
  "default": "{\"name\":\"@user:domain.com\",\"threepids\":[{\"address\":\"[email protected]\",\"medium\":\"email\"}],\"id\":\"@user:domain.com\"}"
}

PUT - /_synapse/admin/v2/users/@user:domain.com

Remove 3PID (Email medium)

CURL

curl -X PUT "https://matrix/_synapse/admin/v2/users/@user:domain.com" \
    -H "Authorization: Bearer AdminToken" \
    -H "Content-Type: application/json; charset=utf-8" \
    --data-raw "$body"

Header Parameters

• Authorization should respect the following schema:

{
  "type": "string",
  "enum": [
    "Bearer AdminToken"
  ],
  "default": "Bearer AdminToken"
}

• Content-Type should respect the following schema:

{
  "type": "string",
  "enum": [
    "application/json; charset=utf-8"
  ],
  "default": "application/json; charset=utf-8"
}

Body Parameters

• body should respect the following schema:

{
  "type": "string",
  "default": "{\"name\":\"@user:domain.com\",\"id\":\"@user:domain.com\"}"
}

For E2EE, we should do something indeed.

What's your idea about key-handling? Pregenerate them and store them where? Do what with them?

There are many issues more or less related to E2EE in corporate environment (e.g. 1, 2, 3).

I try to stay a bit pragmatic in this question. E2EE stays, it's hyped and nice to have for common usage. It's default now. I/We have to live with it - OK. Moreover my/our conclusion is that E2EE is not really prohibited (or regulated) in most corporate environments.

The problem is, that it is simply way too complicated for end-user to set it up and maintain (especially in Matrix/Element). Some significant amount of users come to my helpdesk on a weekly basis asking to restore their regular passwords (sic!). One can imagine what would happen with cross-signing encryption recovery keys (assuming they'd manage to set them up at all). And I can't simply "reset" them, loosing them means loss of sometimes crucial conversations history for end-users.

My thoughts so far:

1. Disable E2EE completely - not really possible at the moment. We have to wait for additional support from Synapse and Element. Workarounds are limited and leave artifacts that are hard to understand for end-users. I personally doubt those issues are in even middle future development pipeline.
2. Upon account creation create a bot for each account that will permanently stay online and verify all new sessions (possibly under some conditions to harden security, e.g. IP whitelisting). I doubt on reliability and scalability of this "solution"
3. Upon account creation login through shared auth, initialize cross-signing and key backup, store the recovery key in a secured corporate environment. Provide it to the user on demand for session recovery. IMHO preferred solution

I tried to implement 3 myself - so far unsuccessful. I guess one has to have much more experience in Synapse infrastructure to understand the whole encryption workflow. It's not a matter of a few hours :(

WDYT? :)

[spantaleev]

Indeed!

It feels like E2EE is pushed fairly hard, while it causes so much complication (UX-wise and feature-wise). It also breaks so many clients, bots, etc.. And then there's the human problem. Regular users can barely remember a single password, and now they have at least one more password. And they're asked to use a different one.. No way..

Having worked on translating Element (web / iOS / Android) and having touched encryption a bit myself (with huge reluctance), I'd rather run away from all this, let alone let any of my family or friends deal with it.

I think it'd be nice if corporal could have support for completely disabling E2EE. I don't know if it intercepting requests would be enough though. Clients may be insistent on setting up keys and "secure secret storage".

Although there are things you can set in /.well-known/matrix/client to hint to Element that you'd like to avoid encryption, it's probably not enough. It's certainly not enough when it comes to federation. These settings only instruct what your Element instance should do. If someone else drags you into an encrypted room (and users over federation will certainly do that to you, because most of them are running an overly-E2EE-aggressive Element), you won't be able to run away.

I'm not sure what a good solution to all this would be.. Do we need an MSC that specifies how cross-server-E2EE negotiation should work?

We may be able to solve it for the local use-case and disable encryption for all rooms your own users create (even if Element tries to enable it). Unfortunately, Element (and other clients) will still nag you to set up keys, secret storage, secure backup and whatnot. And you'll still be invited to encrypted rooms over federation.

---

Another thing is.. matrix-corporal impersonates users and performs actions on their behalf. To do that, it performs a /login, which unfortunately generates a new device right now.. Generating a new device:

• gets announced over federation as far as I know ("you should know, this user has a new device"). This is also a cause of slowdown. If you're part of large rooms, it will notify thousands of other servers about that new device (which will be gone soon anyway).

• gets announced to your other sessions ("verify that other session from your current session?")

This is something else that might be causing problems for us. Possible solutions might be to:

• perform actions on behalf of users by acting as an application service. No devices are created then, from what I know.

• use the new Synapse-specific API for logging in as a user without creating a device. It's being introduced in Synapse v1.24.0 - https://github.com/matrix-org/synapse/pull/8617