End to End Encryption SIG - 2021-08-22

  1. thilo.molitor has left
  2. thilo.molitor has joined
  3. belong has left
  4. beforeigner has left
  5. thilo.molitor has left
  6. thilo.molitor has joined
  7. thilo.molitor has left
  8. neustradamus has left
  9. neustradamus has joined
  10. DebXWoody has joined
  11. beforeigner has joined
  12. belong has joined
  13. thilo.molitor has joined
  14. thilo.molitor has left
  15. thilo.molitor has joined
  16. thilo.molitor has left
  17. beforeigner has left
  18. beforeigner has joined
  19. belong has left
  20. southerntofu has joined
  21. southerntofu hello i'm wondering how OMEMO plays with maintaining several cryptographic identities from the same account for pseudonymous MUCs
  22. belong has joined
  23. christian has left
  24. christian has joined
  25. 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?
  26. DebXWoody has left
  27. 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)
  28. southerntofu (in private messages in pseudonymous MUCs, i meant)
  29. christian Its a great idea to crypt the trafic between servers even for unencrypted.
  30. Millesimus has left
  31. Millesimus has joined
  32. beforeigner Hm? Pseudonymous mucs are public, there is no omemo in whispering.
  33. beforeigner Omemo need to know the client of the other, but we know only the muc server if its no private muc.
  34. 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
  35. southerntofu or have i misunderstood what you said in another channel pep. ?
  36. beforeigner has left
  37. 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.
  38. pep. So yes there can be OMEMO in MUC PMs even if it's not widely used (or even allowed in clients)
  39. MattJ Ok, here's the story...
  40. 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
  41. MattJ That has been happening for a very very long time
  42. 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
  43. MattJ This also allows access to OMEMO prekeys, and any other public nodes published by a user
  44. 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
  45. MattJ Clients are already publishing avatar hashes in their presence, which are also unique for each user
  46. 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...)
  47. pep. For sure I'm not saying prosody is the issue with fingerprinting. Just talking about semi-anon MUCs :)
  48. pep. Vcard-temp would be a thing to solve first..
  49. 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)
  50. MattJ Matrix just avoids this issue by making your address public. Maybe that's better than a false sense of privacy :)
  51. 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.
  52. 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).
  53. MattJ And even if it did, it doesn't solve the stated problem (users can be identified in other ways)
  54. beforeigner has joined
  55. 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?
  56. 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.
  57. vanitasvitae Having different keys per nick would be very complicated I fear.
  58. beforeigner Its still complicated in closed private groups without that many wellknown users often ^^
  59. vanitasvitae Yeah :/
  60. beforeigner Will OX fix this? 😁
  61. beforeigner Will OX fix this all? 😁
  62. MattJ Complicated... meaning some servers/users/clients don't configure their PEP node properly?
  63. MattJ or what other problems are there?
  64. beforeigner If one user has new / aditional key the private group is broken until all received it.
  65. vanitasvitae First of all OX is strictly bound to the user, so anonymous/pseudonymous communication is not possible with OX atm
  66. MattJ beforeigner, ah yes, that makes sense
  67. MattJ By "broken" presumably you mean that the new user/device isn't able to decrypt messages
  68. MattJ and strangers in the group won't receive a notification about the new keys
  69. beforeigner The muc is like freezed, no one can talk or disable encryption (in conversations)
  70. MattJ That sounds like something that shouldn't happen
  71. vanitasvitae Yeah that sounds wrong
  72. MattJ Though I've experienced it when a user is added that has not yet published any keys
  73. MattJ I'm planning an extension that marks a MUC as encrypted, and forbids adding anyone who doesn't have keys
  74. MattJ That's a small step in improving this
  75. 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
  76. 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
  77. beforeigner Thats how it sounds whats written in support chats where not that much techy newbees are..
  78. 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.
  79. MattJ Just use an account per identity, and you'll be 90% of the way to solving it
  80. southerntofu so is it your opinion pseudonymity in MUCs should be removed completely because it gives a false sense of security?
  81. beforeigner I think in a full client you can change much more settings to conter the freeze. Idk.
  82. MattJ No, as I said it is still good to mask the user's real JID
  83. 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
  84. 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)
  85. MattJ Yes, sure. Assume facial recognition cameras at each event (an increasingly wise assumption).
  86. 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
  87. MattJ Unlike IRL though, it's possible to create multiple accounts in XMPP
  88. southerntofu of course the assumption is that not every client is going to implement it and backwards-compatibility is primordial
  89. 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
  90. thilo.molitor has joined
  91. thilo.molitor has left
  92. southerntofu vanitasvitae, really interesting idea to have an account-level key to sign client subkeys
  93. southerntofu (reading your draft now)
  94. vanitasvitae southerntofu, hehe its stright up stolen from the matrix guys 😛
  95. vanitasvitae apart from using OpenPGP
  96. 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)
  97. vanitasvitae Well, you could sign some migration statement
  98. vanitasvitae Eg. in combination with the Moved spec
  99. southerntofu exactly the type of stuff i had in mind
  100. southerntofu would be useful when your previous server is down, to authenticate the legitimacy of the request against your contacts
  101. vanitasvitae Yep
  102. DebXWoody has joined
  103. 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
  104. moparisthebest has left
  105. Millesimus has left
  106. Millesimus has joined
  107. moparisthebest has joined
  108. DebXWoody has left
  109. thilo.molitor has joined
  110. beforeigner has left
  111. beforeigner has joined
  112. beforeigner has left
  113. beforeigner has joined
  114. melvo has joined
  115. beforeigner has left
  116. christian has left
  117. christian has joined
  118. christian has left