End to End Encryption SIG - 2021-08-22

  1. southerntofu

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

  2. southerntofu

    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?

  3. southerntofu

    (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)

  4. southerntofu

    (in private messages in pseudonymous MUCs, i meant)

  5. christian

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

  6. beforeigner

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

  7. beforeigner

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

  8. southerntofu

    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

  9. southerntofu

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

  10. 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.

  11. pep.

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

  12. MattJ

    Ok, here's the story...

  13. MattJ

    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

  14. MattJ

    That has been happening for a very very long time

  15. MattJ

    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

  16. MattJ

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

  17. MattJ

    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

  18. MattJ

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

  19. MattJ

    (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...)

  20. pep.

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

  21. pep.

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

  22. MattJ

    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)

  23. MattJ

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

  24. MattJ

    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.

  25. MattJ

    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).

  26. MattJ

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

  27. beforeigner

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

  28. MattJ

    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.

  29. vanitasvitae

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

  30. beforeigner

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

  31. vanitasvitae

    Yeah :/

  32. beforeigner

    Will OX fix this? 😁

  33. beforeigner

    Will OX fix this all? 😁

  34. MattJ

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

  35. MattJ

    or what other problems are there?

  36. beforeigner

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

  37. vanitasvitae

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

  38. MattJ

    beforeigner, ah yes, that makes sense

  39. MattJ

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

  40. MattJ

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

  41. beforeigner

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

  42. MattJ

    That sounds like something that shouldn't happen

  43. vanitasvitae

    Yeah that sounds wrong

  44. MattJ

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

  45. MattJ

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

  46. MattJ

    That's a small step in improving this

  47. southerntofu

    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

  48. southerntofu

    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

  49. beforeigner

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

  50. MattJ

    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.

  51. MattJ

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

  52. southerntofu

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

  53. beforeigner

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

  54. MattJ

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

  55. MattJ

    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

  56. southerntofu

    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)

  57. MattJ

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

  58. southerntofu

    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

  59. MattJ

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

  60. southerntofu

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

  61. southerntofu

    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

  62. southerntofu

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

  63. southerntofu

    (reading your draft now)

  64. vanitasvitae

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

  65. vanitasvitae

    apart from using OpenPGP

  66. southerntofu

    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)

  67. vanitasvitae

    Well, you could sign some migration statement

  68. vanitasvitae

    Eg. in combination with the Moved spec

  69. southerntofu

    exactly the type of stuff i had in mind

  70. southerntofu

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

  71. vanitasvitae


  72. southerntofu

    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