Modern XMPP project discussion - 2023-09-20


  1. mirux

    will the "enhancement" of the signal protocol "quantum resistance" also adopted in the xmpp world? https://signal.org/blog/pqxdh/

  2. MattJ

    I suspect moving to MLS is more likely to happen sooner than significant changes to OMEMO

  3. MSavoritias (fae,ve)

    i cant help but feel that is avoiding the problem though :/

  4. MattJ

    Which problem?

  5. MSavoritias (fae,ve)

    it the sense that the problems of lack of implementation, verification and everything else is still gonna exist with MLS

  6. MSavoritias (fae,ve)

    in client implementations that is

  7. MattJ

    MLS has multiple independent implementations, it has formal verification, etc. and is a proper scrutinized standard outside of the XMPP sphere

  8. MattJ

    OMEMO is basically just us

  9. MSavoritias (fae,ve)

    so either all clients use one implementation which is problematic (see webp) and magically everything is fixed. (i doubt it though because clients still need to implement protocol specific stuff)

  10. MattJ

    MLS also adds features, such as proper support for groups

  11. Link Mauve

    MSavoritias (fae,ve), there are other webp implementations than libwebp.

  12. MSavoritias (fae,ve)

    my main issue i guess is that the xmpp community hasnt shown much willingness to fix the omemo stuff or adopt so moving to mls wont really fix the cultural problems

  13. Link Mauve

    The two browsers use it, but it is far from the only existing one.

  14. MSavoritias (fae,ve)

    > MSavoritias (fae,ve), there are other webp implementations than libwebp. maybe. from what ive read half the internet was affected anyway

  15. MattJ

    XMPP's problem isn't always the willingness

  16. MSavoritias (fae,ve)

    true. it will fix the implementation part as you said

  17. MattJ

    I think if we could click our fingers and magic OMEMO2 (and OMEMO3) into existence in all implementations, we would

  18. MattJ

    But the reality is that it is *extremely* hard to do that

  19. MattJ

    Not impossible, but hard

  20. MSavoritias (fae,ve)

    im not talking about only adoption of omemo2 though

  21. MSavoritias (fae,ve)

    there has been problems with verification of a lot of devices, old keys still appearing and groups not working for years

  22. MSavoritias (fae,ve)

    or the this message cant be decrypted

  23. MattJ

    Right, because E2EE is super hard, and we're not a community of cryptographers

  24. MSavoritias (fae,ve)

    so i fear that MLS will fix the implementation part

  25. MSavoritias (fae,ve)

    but all the rest protocol/client specific problems will still be there

  26. MattJ

    MLS is the work of multiple actual cryptographers working together to solve the problems that OMEMO has

  27. MattJ

    and get that into a standard that people can use

  28. MSavoritias (fae,ve)

    you mean it solves also the random decryption problems and the too many keys thing among others?

  29. MattJ

    Yes

  30. MSavoritias (fae,ve)

    well lets wait and see then

  31. MattJ

    OMEMO (and Signal) don't *really* support groups, they hack it by pretending everyone is sending to everyone else

  32. MSavoritias (fae,ve)

    i did hear that it has worse metadata protection than omemo

  33. MattJ

    MLS has native support for groups, everything is well-defined

  34. MSavoritias (fae,ve)

    omemo 2 that is

  35. MSavoritias (fae,ve)

    > MLS has native support for groups, everything is well-defined yeah i am aware it fixes groups.

  36. MattJ

    I don't know about that, I haven't studied OMEMO1 vs OMEMO2

  37. MattJ

    MLS has (theoretically) better metadata protection, such as being able to hide group membership

  38. MattJ

    But I don't know if we'll achieve that in XMPP

  39. MSavoritias (fae,ve)

    i do think that trying to fix omemo at this point for groups is probably stupid

  40. MSavoritias (fae,ve)

    when MLS exists

  41. MattJ

    I don't know how it could reasonably be fixed

  42. MSavoritias (fae,ve)

    but i need to read if its worse than omemo:2 or the same. if it can have the same metadata protection i dont see anypoint then even keeping omemo for 1:1 chats

  43. MSavoritias (fae,ve)

    even if it can i dont think i see the point personally

  44. MSavoritias (fae,ve)

    we are just duplicating what is already there

  45. MSavoritias (fae,ve)

    okay so I read the MLS rfc and the omemo rfc a bit. you were right MattJ reading through mls it does have metadata protection. the only thing that it doesnt have is deniability which is not mentioned. but omemo has weak deniability either way.

  46. MSavoritias (fae,ve)

    so Im guessing there is no point then imo to look into omemo for any future projects at this point. ill skip it and go straight to mls

  47. MSavoritias (fae,ve)

    although im not sure what library im going to use either way.

  48. Link Mauve

    MSavoritias (fae,ve), before a library you will probably want to define a protocol mapping it to XMPP.

  49. Link Mauve

    I’ve had good feedback from a friend about openmls, but I haven’t used it yet.

  50. MSavoritias (fae,ve)

    of course. but at least i know i dont have to bother with two encryptions now

  51. MSavoritias (fae,ve)

    omemo and mls. and can just go full mls

  52. MSavoritias (fae,ve)

    im guessing a xep will also define the cyphers

  53. Link Mauve

    Depends whether you want to be compatible with any current client or not.

  54. MSavoritias (fae,ve)

    of course :P