[gefhfffh]

How resistant to MITM is it though?

Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time.

Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of the old times in [matrix].

This opens room for MITM attacks

[f1refly]

Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere?

Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key.

In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident.

> This opens room for MITM attacks

Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.

[southerntofu]

> How should a "per user" verification work in your opinion?

The server could keep an append-only log of published keys, and then you could require m-of-n signatures of other published devices/keys to register a new one, in which case no further verification would be verifiable if you already trusted your peer's other keys. In addition, you could introduce peer keys in private rooms automatically and/or employ some form zero-knowledge proofs in public venues.

XEP-0450 Automated Trust Management is a first exploration in this direction. There a lot to explore and I only wished skilled cryptographers spent more time researching these issues on federated networks instead of advancing yet-another-centralized-messenger-of-the-month.

> Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that.

Also known as a keyserver. But you could also employ cryptographic challenges like OTR does, like a shared password to establish the session.

[easrng]

Why not do crosssigning like matrix?

[ddtaylor]

That sounds significantly more complex and worse than how Matrix just works out of the box.

[f1refly]

Omemo just works out of the box as well. You don't have to check the key fingerprints, noone forces you to. For people who aren't interested the chat opens and they can start writing and sending, the encryption is completely transparent.

[doctor_lollipop]

I wouldn't say that it's completely transparent, at least not when you use multiple clients (eg. a PC and a phone). I frequently get messages that some device cannot decrypt.