End to End Encryption SIG - 2021-08-22

hello i'm wondering how OMEMO plays with maintaining several cryptographic identities from the same account for pseudonymous MUCs

as i understand it some MUC servers relay key discovery to ease the process in pseudonymous MUC, however does that not represent a metadata leak tying several nicknames to the same keypair? should clients not manage one bundle per MUC*nick pair since OMEMO in pseudonymous MUC is TOFU-based anyway?

(i don't see it defined in the spec how to handle different groups of bundles and how to query them specifically dpeending on the context)

(in private messages in pseudonymous MUCs, i meant)

Its a great idea to crypt the trafic between servers even for unencrypted.

Hm? Pseudonymous mucs are public, there is no omemo in whispering.

Omemo need to know the client of the other, but we know only the muc server if its no private muc.

i heard, maybe not correct though, that some clients do omemo in private chats in MUCs and that in that case some MUC servers proxy the request (because the clients are not aware of one another's JID) but maybe i've been misinformed? i haven't actually tried

or have i misunderstood what you said in another channel pep. ?

beforeigner: it depends on the MUC. Prosody translates the mucjid to real jid for PEP so one can get the keys if the node is open.

So yes there can be OMEMO in MUC PMs even if it's not widely used (or even allowed in clients)

Ok, here's the story...

Avatars in semianonymous MUCs wouldn't work today, except for the fact that MUC services all handle vcard-temp stanzas on occupant JIDs, and redirect them to the user bare JIDs

That has been happening for a very very long time

We're moving to avatars and vcards in PEP, and these days Prosody will handle PEP requests in the same way as vcard-temp requests for MUC occupants

This also allows access to OMEMO prekeys, and any other public nodes published by a user

If the concern is client fingerprinting/tracking in semianonymous MUCs, I don't think this is a new issue at all, even without this change in Prosody there are many ways you could figure out whether two semianonymous MUC occupants were the same user/account/client

Clients are already publishing avatar hashes in their presence, which are also unique for each user

(loose definition of "unique" - someone could copy someone else's avatar/hash, just as they could also republish someone else's OMEMO keys, but that would be more obvious...)

For sure I'm not saying prosody is the issue with fingerprinting. Just talking about semi-anon MUCs :)

Vcard-temp would be a thing to solve first..

Just want to make clear the reasoning, and the context. Since I've seen this Prosody change raised every time, but it really doesn't change much in the context of user identification (a topic I don't think anyone has really cared for, and it's a hard one)

Matrix just avoids this issue by making your address public. Maybe that's better than a false sense of privacy :)

But there is still value in masking your real address, I think. Even if you're not protected from someone identifying that you are the same person in multiple MUCs.

Anyway, this is a tangent to E2EE and the original question. I think the answer to the original question is that OMEMO does not try to solve this issue (and it's not clear how it could, while using PEP).

And even if it did, it doesn't solve the stated problem (users can be identified in other ways)

So than every muc join needs to receive the whole keyset of every participant, or just that one set the pm is started with?

No, the keys are currently published to the user's account on their server. Prosody's MUC implementation just allows you to query them without knowing the user's real JID.

Having different keys per nick would be very complicated I fear.

Its still complicated in closed private groups without that many wellknown users often ^^

Yeah :/

Will OX fix this all? 😁 ✏

Complicated... meaning some servers/users/clients don't configure their PEP node properly?

or what other problems are there?

If one user has new / aditional key the private group is broken until all received it.

First of all OX is strictly bound to the user, so anonymous/pseudonymous communication is not possible with OX atm

beforeigner, ah yes, that makes sense

By "broken" presumably you mean that the new user/device isn't able to decrypt messages

and strangers in the group won't receive a notification about the new keys

The muc is like freezed, no one can talk or disable encryption (in conversations)

That sounds like something that shouldn't happen

Yeah that sounds wrong

Though I've experienced it when a user is added that has not yet published any keys

I'm planning an extension that marks a MUC as encrypted, and forbids adding anyone who doesn't have keys

That's a small step in improving this

MattJ, hello sorry i didn't mean to imply this is a problem specific to prosody (in fact i'm glad that's prosody's behavior because it enables OMEMO in private messages in MUCs) or that it's a problem specific to OMEMO

but i am interested in solving this problem and i think specs should leave room for that, hence my question about multiple identities in OMEMO

Thats how it sounds whats written in support chats where not that much techy newbees are..

southerntofu, I'm just going to say it... I don't think you can solve this problem. Doing it in a way that guarantees two nicks cannot be linked is extremely tricky, and requires changes across a bunch of different protocol areas, and very careful implementation by clients.

Just use an account per identity, and you'll be 90% of the way to solving it

so is it your opinion pseudonymity in MUCs should be removed completely because it gives a false sense of security?

I think in a full client you can change much more settings to conter the freeze. Idk.

No, as I said it is still good to mask the user's real JID

If I attend two separate IRL events and someone recognizes me, that's very different to walking into each event with my home address written on a sticky note on my forehead

in this analogy can we assume occupant-id, avatar hash and OMEMO/OX fingerprints are like tattoos on the forehead which can very easily be tracked via passive surveillance? (despite not being a home address)

Yes, sure. Assume facial recognition cameras at each event (an increasingly wise assumption).

i'd be interested in a specification for improvement security profile, client-side.. sort of like "safe browsing" mode for webbrowsers where it could be defined as a set of best practices for clients to follow in order to prevent unexpected metadata leaks

Unlike IRL though, it's possible to create multiple accounts in XMPP

of course the assumption is that not every client is going to implement it and backwards-compatibility is primordial

yes multi account UX is nice, but the problem is with advertizing MUCs as pseudonymous when there are mechanisms which break pseudonymity, which i believe is relevant to this chatroom but please let me know if it's not

vanitasvitae, really interesting idea to have an account-level key to sign client subkeys

(reading your draft now)

southerntofu, hehe its stright up stolen from the matrix guys 😛

apart from using OpenPGP

vanitasvitae, slightly off-topic, but i'm tangentially interested in how such account-level crypto-identity can also be useful for account migration across servers, like in the ZOT protocol (hubzilla)

Well, you could sign some migration statement

Eg. in combination with the Moved spec

exactly the type of stuff i had in mind

would be useful when your previous server is down, to authenticate the legitimacy of the request against your contacts

Yep

it's offtopic but we can probably continue the discussion about account keys in modernxmpp@rooms.modernxmpp.org for account migration bits, or privacy@joinjabber.org for broader crypto-identity/metadata related discussions