3 ms·

This is the MSC you mentioned? https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md

This is the MSC you mentioned? https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md https://github.com/matrix-org/matrix-doc/blob/rav/proposal/r... I love the idea of using public keys as identifiers, but to be honest the current proposal does NOT give me a warm fuzzy feeling inside. First, you’re having the server generate keys for the users. This is at best a “code smell” —- even if it works for your particular security goals, it sure feels weird. Zoom recently got absolutely blasted (and rightly so) for doing something similar. Why not have the user generate their own keypair, and then the server can sign the public half, essentially giving you a cert. Second, there’s a lot of places where you have a layer of indirection between old @user:domain id’s and the new public keys. As an attacker, I would see every one of those places as extra attack surface where I might be able to exploit some confusion. I hope this doesn’t come off as excessively negative. Matrix is awesome and you’re all doing a great job tackling some huge problems.

Arathorn 6y ago
Yup, that's the right link, but I think you've misunderstood the intention of MSC1228. The user identity keys are not used for encryption, let alone end-to-end encryption. These are of course only ever created on clients, and never leave the clients. Instead, this is just a proposal for how to determine what servers are allowed to host a given identity. The proposal also predates E2E - nowadays we might also sign the keys with your E2EE keys to lock the chain of trust to the client. I get why the whole indirection from @foo:bar.com through to new public keys might also feel weird, but in practice we have that indirection today - as you resolve (say) an email address to a matrix ID. It's basically making the old matrix IDs equivalent to today's 3rd party IDs (email or phone number or whatever). So yup, understood that it smells funny, but I think the concerns aren't entirely well-founded here. That said, the proposal is ~2 years old, and we'll be dusting it off and sorting it out in the coming months in order to support P2P and speed up room joins, and that might be the point where we tie it into E2EE keys (or not).
- cvwright 6y ago
  Ah ok that does make me feel better. I’ll try to take a closer look when I have time. Thanks!

Arathorn 6y ago

Yup, that's the right link, but I think you've misunderstood the intention of MSC1228. The user identity keys are not used for encryption, let alone end-to-end encryption. These are of course only ever created on clients, and never leave the clients. Instead, this is just a proposal for how to determine what servers are allowed to host a given identity. The proposal also predates E2E - nowadays we might also sign the keys with your E2EE keys to lock the chain of trust to the client. I get why the whole indirection from @foo:bar.com through to new public keys might also feel weird, but in practice we have that indirection today - as you resolve (say) an email address to a matrix ID. It's basically making the old matrix IDs equivalent to today's 3rd party IDs (email or phone number or whatever). So yup, understood that it smells funny, but I think the concerns aren't entirely well-founded here. That said, the proposal is ~2 years old, and we'll be dusting it off and sorting it out in the coming months in order to support P2P and speed up room joins, and that might be the point where we tie it into E2EE keys (or not).

cvwright 6y ago
Ah ok that does make me feel better. I’ll try to take a closer look when I have time. Thanks!