End to End Encryption SIG - 2022-11-10

  1. belong has joined

  2. atomicwatch has left

  3. tom-6271 has joined

  4. atomicwatch has joined

  5. tom-6271 has left

  6. atomicwatch has left

  7. atomicwatch has joined

  8. Titi has joined

  9. atomicwatch has left

  10. atomicwatch has joined

  11. tom-6271 has joined

  12. atomicwatch has left

  13. atomicwatch has joined

  14. atomicwatch has left

  15. atomicwatch has joined

  16. dequbed has joined

  17. Jeroen has joined

  18. Jeroen has left

  19. L29Ah has left

  20. Jeroen has joined

  21. Jeroen has left

  22. MSavoritias (fae,ve) has joined

  23. Jeroen has joined

  24. Jeroen has left

  25. atomicwatch has left

  26. atomicwatch has joined

  27. atomicwatch has left

  28. atomicwatch has joined

  29. tritium has joined

  30. Titi has left

  31. L29Ah has joined

  32. Jeroen has joined

  33. Jeroen has left

  34. Millesimus has left

  35. Titi has joined

  36. Jeroen has joined

  37. Jeroen has left

  38. Jeroen has joined

  39. Jeroen has left

  40. MattJ

    I hate to say this in the middle of the TWOMEMO roll-out, but... anyone interested in MLS?

  41. trollge

    MattJ: what is any of that

  42. MattJ

    End-to-end encryption

  43. melvo has left

  44. MattJ


  45. Jeroen has joined

  46. Millesimus has joined

  47. MSavoritias (fae,ve)

    Is MLS actually being deployed anywhere? I thought it was still in its infancy

  48. dequbed

    It's not yet deployed, no. But it's at the stage where an Implementation of the Transport layer using XMPP could start to be defined & implemented

  49. Millesimus has left

  50. MattJ

    MSavoritias (fae,ve), a beta roll-out for at least one (open-source) product is expected very soon. I don't know if that's public information, but here's an interesting repo I found: https://github.com/wireapp/core-crypto ;)

  51. MattJ

    It's still in its infancy, but it's starting to take its first steps

  52. MattJ

    Maybe they'll be wobbly steps, but now is a good time to figure out if/how we can/want to map this to XMPP

  53. MattJ

    MLS is basically a hard requirement for MIMI at this point, which is why I'm bringing it up right now

  54. MSavoritias (fae,ve)

    Yeah i saw in the meeting. Its built on top

  55. Millesimus has joined

  56. MSavoritias (fae,ve)

    I think its all up to: Will we have gateways that support e2e encryption in MLS

  57. MSavoritias (fae,ve)

    Because that seems like the whole point of it imo

  58. MattJ

    Gatekeepers you mean?

  59. MattJ

    Nobody can predict, and they haven't said anything officially so far, but there are indications that they're at least interested

  60. MattJ

    But even if we don't do it for MIMI, there may be other reasons

  61. MattJ

    It's more scalable than OMEMO, and has some nice security/privacy features, such as cryptographically-assured group membership (the lack of which bit Matrix hard, if you saw their recent security flaws announced)

  62. MattJ

    We barely even try to have that now, with OMEMO. Just a confirmation screen in Conversations that people complain about :)

  63. MattJ

    If we do certain things in certain ways, we can also go some way towards hiding group membership from the group service itself

  64. MSavoritias (fae,ve) has left

  65. MattJ

    Also, Matrix may never get MLS, as it's not very suited to the eventual consistency model it uses. That might be something interesting to further differentiate the two protocols.

  66. MattJ

    and if they do, who knows, we might get a decent bridge thanks to MIMI

  67. MSavoritias (fae,ve) has joined

  68. MSavoritias (fae,ve)

    So you are thinking of using mls for group encryption since its basically unarealistic in omemo? I could see that being very desirable

  69. MSavoritias (fae,ve)

    > MattJ: > Gatekeepers you mean? I meant generally gateways. Like to wire, signal and the likes. So we van send messages encrypted over the bridge

  70. MattJ

    Traditional gateways can't support E2EE, because it prevents them from performing the necessary translation between the protocols

  71. MattJ

    Unless you consider the gateway one of the E's

  72. MattJ

    Which most people obviously don't want to do

  73. MattJ

    With MIMI+MLS that may change

  74. MSavoritias (fae,ve)

    Yeah that was my thinking

  75. MattJ

    There is more chance of other platforms adopting MLS than adopting OMEMO

  76. belong has left

  77. MSavoritias (fae,ve)

    I agree. That is why i was saying the whole value proposition of MLS would be if it gets adopted in other services and we can do e2e over the gateway with MIM.

  78. MattJ

    So I think there are many interesting reasons we should be looking at MLS in XMPP, even if MIMI doesn't succeed

  79. MSavoritias (fae,ve)

    Now if its also better for groups than omemo then i would say its definetily worth it to have it. Since the group encryption in xmpp is pretty much broken with omemo

  80. MSavoritias (fae,ve)


  81. MattJ

    It's much better for groups, and designed to scale much better than the existing solutions

  82. MattJ

    We have challenges though, such as... can we use it in 1:1? do we want to?

  83. MattJ

    Some platforms model 1:1 as a 2-person group, but XMPP does not

  84. MattJ

    It makes a difference. In MLS the group service enforces some rules, such as ensuring everyone gets a consistent ordering of events.

  85. tritium has left

  86. MattJ

    In 1:1, there is no such authority over the communication, each user's server is simply a peer to the other

  87. MattJ

    I heard some interesting solutions to that, such as making two fake groups, one on each server, and keeping two separate (but equivalent) states.

  88. MattJ

    Seems complicated though, so we might want to just start with using it for groups

  89. MSavoritias (fae,ve)

    Yeah i think replacinp everything with it is unrealistic right now. But for groups i think everybody will agree its a better solution than omemo. Except OX people

  90. MSavoritias (fae,ve)

    Personally i think its to XMPP benefit that we seperate 1:1 and groups. Because we can havn different properties for each.

  91. MSavoritias (fae,ve)

    Could be just me though

  92. MattJ

    Yeah, I generally prefer our model

  93. MattJ

    It has pros and cons, but I like that it is simple and intuitive to send a message from A to B

  94. MSavoritias (fae,ve)

    I remember matrix having issues with everything being room also

  95. MSavoritias (fae,ve)


  96. MattJ

    Yes, such as two people potentially having multiple rooms between them

  97. MattJ

    Gets complicated to hide such situations from users, who think they are just messaging each other directly

  98. MSavoritias (fae,ve)

    Yeah. They had to implement them as 1:1 persistent rooms or something

  99. melvo has joined

  100. tritium has joined

  101. *IM* has left

  102. *IM* has joined

  103. trollge has left

  104. Link Mauve

    Compared to oldmemo and twomemo, where does MLS fit regarding “full stanza encryption”?

  105. Link Mauve

    If the thing we encrypt is an XMPP stanza, I highly doubt other protocols will be able to interoperate with us.

  106. Link Mauve

    But if we go the oldmemo way and encrypt only the body of a message, it’s going to be the same bad thing where we have to disable every single advanced feature of XMPP.

  107. Millesimus has left

  108. tom-6271 has left

  109. trollge has joined

  110. *IM* has left

  111. *IM* has joined

  112. yvo has joined

  113. *IM* has left

  114. belong has joined

  115. tritium has left

  116. *IM* has joined

  117. Jeroen has left

  118. Jeroen has joined

  119. Jeroen has left

  120. Jeroen has joined

  121. Jeroen has left

  122. atomicwatch has left

  123. Millesimus has joined

  124. atomicwatch has joined

  125. atomicwatch has left

  126. atomicwatch has joined

  127. Jeroen has joined

  128. Jeroen has left

  129. Jeroen has joined

  130. Jeroen has left

  131. tom-6271 has joined

  132. melvo has left

  133. *IM* has left

  134. atomicwatch has left

  135. Jeroen has joined

  136. Jeroen has left

  137. Jeroen has joined

  138. Jeroen has left

  139. Jeroen has joined

  140. *IM* has joined

  141. atomicwatch has joined

  142. Jeroen has left

  143. Jeroen has joined

  144. dequbed

    I mean E2EE gateways isn't the goal of MLS. Just because you all use TLS doesn't imply your protocols are compatible all of a sudden, does it? The primary idea was to develop a proper, well-designed specification that is specified in a way that makes it very easy for libraries to be absolutely agnostic of the actual protocol, just like TLS is designed to not need to care about the protocol it protects, or the transport layer technology. MLS will improve the security of chat by providing developers with high-quality cryptographic libraries they can use, just like OpenSSL et.al. improved the state of the art in transport layer encryption.

  145. tom-6271 has left

  146. atomicwatch has left

  147. king has left

  148. larma has left

  149. larma has joined

  150. *IM* has left

  151. atomicwatch has joined

  152. Jeroen has left

  153. tom-6271 has joined

  154. atomicwatch has left

  155. Jeroen has joined

  156. *IM* has joined

  157. king has joined

  158. *IM* has left

  159. MSavoritias (fae,ve) has left

  160. MSavoritias (fae,ve) has joined

  161. larma has left

  162. larma has joined

  163. MSavoritias (fae,ve) has left

  164. MSavoritias (fae,ve) has joined

  165. tom-6271 has left

  166. melvo has joined

  167. *IM* has joined

  168. larma

    If Matrix and XMPP were both to use MLS, I could imagine a gateway transporting encrypted JSON / XML payloads and clients on both sides actually understanding both. Adding a second translation to internal data structure is probably not too hard. Maybe not all features will be supported, but at least some can be done. Of course it would be even better if we could build a common standard for the encrypted payload. A standard with a democratically-elected committee deciding on what is accepted, with various optional extensions, ... - something like XMPP and very much unlike Matrix, so it's not going to happen

  169. trollge has left

  170. trollge has joined

  171. MSavoritias (fae,ve)

    Yeah.. But then again i dont think gateways can guarantee much more than text. And judging by the other gateways matrix developed it doesnt even look desirable

  172. vanitasvitae

    The soft requirement of having a shared payload format is what makes MLS uninteresting for me (yet).

  173. vanitasvitae

    I think once the MIMI group settles on a shared format, MLS gets really interesting

  174. vanitasvitae

    Does anyone know what the library ecosystem for MLS is looking like?

  175. melvo has left

  176. *IM* has left

  177. *IM* has joined

  178. *IM* has left

  179. *IM* has joined

  180. trollge has left

  181. MattJ

    vanitasvitae, I have been told that there are two main active implementations, both in Rust

  182. MattJ

    One is https://github.com/wireapp/openmls - the other is by Cisco I think, but I'm not sure of the name

  183. vanitasvitae

    I see

  184. trollge has joined

  185. MattJ

    The response to the several comments about MLS being uninteresting while the encrypted payloads are incompatible: defining a standard format for the encrypted payloads is one of the goals of MIMI

  186. MattJ

    Otherwise, yes, MLS alone doesn't magically get you the interop

  187. MattJ

    So basically MIMI is what larma said. Nobody knows what the "content format" (is what they're calling it) will look like yet, but I've no doubt everyone involved has an opinion that will be shared in the coming months

  188. MattJ

    I'm also of the opinion that if we want this interop (assuming MIMI gets picked up by others) then yeah, XMPP clients will need to support this content format and I'd like to think it wouldn't be too hard (I doubt they're going to use XMPP XML, but you never know)

  189. melvo has joined

  190. larma

    I think any attempt to standardize the content format is doomed to fail. You can probably get consensus to have something like a JSON with a field `type` that can be `message` and a field `body`, and agree that this should include an unformatted text representation of the message's body and then vendors can add any additional fields or types - but everything beyond that I've serious doubt it would be widely accepted and even that is unlikely. Different messengers have different UX expectations and thereby different protocol requirements, even when we're only talking about the messages itself.

  191. larma

    I mean we already struggle to find a common standard for message formatting within XMPP (XHTML-IM, Styling, Markup, ...)

  192. tom-6271 has joined

  193. trollge has left

  194. trollge has joined

  195. trollge has left

  196. trollge has joined

  197. MattJ

    Yep. But it's not impossible to imagine that *something* gets standardized. Not saying it will be something great :)

  198. MattJ

    And we'll be back to the same old thing: UX of bridged chats < UX of native chats

  199. belong has left

  200. trollge has left

  201. trollge has joined

  202. Titi has left

  203. Titi has joined

  204. trollge has left

  205. Alastair Hogge has left

  206. MSavoritias (fae,ve) has left

  207. moparisthebest

    > high-quality cryptographic libraries they can use, just like OpenSSL Strange, a shiver just went down my spine

  208. Jeroen has left

  209. Millesimus has left

  210. Millesimus has joined

  211. atomicwatch has joined

  212. atomicwatch has left

  213. Jeroen has joined

  214. Jeroen has left

  215. atomicwatch has joined

  216. atomicwatch has left

  217. belong has joined

  218. Jeroen has joined

  219. Jeroen has left

  220. Alastair Hogge has joined

  221. yvo has left

  222. atomicwatch has joined

  223. atomicwatch has left

  224. atomicwatch has joined

  225. Millesimus has left

  226. Millesimus has joined

  227. atomicwatch has left

  228. atomicwatch has joined