jdev - 2022-01-11

  1. defanor

    The OMEMO XEP doesn't provide a way to ensure that all the connected clients/resources have matching key bundles published, does it?

  2. pep.

    It doesn't, no

  3. defanor

    Seems like if it (as well as the OpenPGP one) did, clients could take that responsibility from a user (i.e., at least show whether decryption issues seem likely), making the usage a bit easier.

  4. flow

    can't a client discover if his bundle is published?

  5. defanor

    AIUI a client can check whether its own bundle is published, since they know their own device ID, but others (those who want to send them a message) can't check IDs of all the connected devices.

  6. pep.

    defanor, you can deduce it, but yeah there's no explicit mechanism to get this information

  7. pep.

    You see a new deviceid in the list you can't associate it right away

  8. flow

    defanor, why just *connected* devices?

  9. flow

    wouldn't you want to also check for offline devices too?

  10. defanor

    Well, with connected ones it at least seems possible; offline ones may include future ones if we're considering history/offline messages.

  11. flow

    it appears that this boils down that we don't have a way to register and unregister user devices, and even if we had, it would probably be not absolutely reliable

  12. flow

    I am not sure why it should be the possiblity of the sending entity to ensure that the receiving entity has published all bundles

  13. flow

    even if the sending entity could determine that a bundle is missing, it can't do much about it

  14. flow

    also the receiving entity has an inventive to ensure that the bundles of all their devices are up-to-date

  15. flow

    *should be the *responsibility* of the sending entity

  16. defanor

    Here's the awkward situation that happens sometimes: a user (receiving entity) connects from two clients/devices, only one publishes the keys, incoming messages get encrypted, the user is confused. They indeed should publish keys from every client or from none now, to ensure reliable delivery, and only stick to clients supporting those then, but it's not the sort of thing most users know about or do, I think. I'm even hesistant myself to publish the keys, since I may have to connect using a client without OMEMO or OpenPGP support, and then there will be all the awkwardness with lost messages again.

  17. flow

    there shouldn't be any lost message, but potentially warning messages from the receiving client that the received message could not be encrypted

  18. flow

    (in an ideal world that is)

  19. defanor

    Yeah, that's the best-case scenario; I saw them both hidden/eaten by a client, and just that situation where you have to ask the other party to disable the encryption and resend messages.

  20. flow

    defanor, I am also not sure what your idea to improve the situtation exactly is?

  21. flow

    because I feel any "improvement" could lead to open up a encryption downgrade attack vector

  22. flow

    because I feel any "improvement" could lead to open up an encryption downgrade attack vector

  23. flow

    basically UX with mixed OMEMO and non-OMEMO clients is sometimes terriable and I think there is not much you can do about it

  24. flow

    basically UX with mixed OMEMO and non-OMEMO clients is sometimes terrible and I think there is not much you can do about it

  25. defanor

    I think if it was possible at least to find out whether currently connected target user's devices seem capable of decrypting messages, it'd mitigate the issue: the sending client's UI would be able to show what to expect. That's far from perfect too, but better than to not know even whether to expect the connected clients to be able to read (decrypt) the message.

  26. flow

    well if you have presence subscription to the receiving entity, then you could query the clients for the omemo feature

  27. flow

    although, I am not sure if the omemo xep currently says that clients should annouce such a feature

  28. flow

    so yes, mandating that clients annouce that feature and having the sending entity check if all clients support it, could maybe improve the situation a bit

  29. defanor

    Supporting a feature at all is indeed a suggestion that they potentially can decrypt messages, but knowing that the keys are published by those clients/devices gives a bit more certainty still.

  30. pep.

    « flow> although, I am not sure if the omemo xep currently says that clients should annouce such a feature » also that doesn't say they're actually using it at the moment you query

  31. flow

    of course, it's a bandaid

  32. flow

    and I believe the don't want that kind of logic in encrypted messaging

  33. MattJ

    FWIW this is something I intend to add to Snikket in the future (server-side sanity check that all your devices have published keys)

  34. pep.

    I guess Snikket can do that because it's Snikket

  35. MattJ

    It's just a little tricky when we don't currently know what devices exist

  36. MattJ

    pep.: partly, though it would be sensible to have some all-or-nothing check for other servers too

  37. pep.

    My poezio OMEMO plugin is temporarily borked, should I prevent people from sending encrypted messages to me at all?

  38. MattJ

    That's up to you 🙂

  39. pep.

    Or am I condemned to receive encrypted messages at all times? :x

  40. MattJ

    If you publish keys.... pretty much yes

  41. MattJ

    Even if only one of your clients published keys, that's it

  42. pep.

    That's in theory, and in some threat model

  43. jonas’

    no, that's what happens in practice ;)

  44. pep.

    No it's not, maybe only with that-one-client

  45. pep.

    Or maybe in Snikket

  46. jonas’

    and you can't control what clients other people use

  47. jonas’

    so it's what happens in practice :)

  48. pep.

    Practice is a mix of all this

  49. pep.

    Atm I'd say the behaviour much more depends on what the user has set their client to do in a specific tab. If it's set to encrypt then surely the client will encrypt as long as the user doesn't change the setting. Dino for sure doesn't change when the recipient has published keys, I've been bitten multiple times when opening a tab I had never opened (1:1 or group). And I'm sure there's also some of this in C. If the other side starts sending me unencrypted messages, I'll continue sending messages not because C "knows" it was encrypted before but because it's now configured to encrypt

  50. qy

    now i remember why i burnt out on rewriting to c++

  51. qy

    having to write a snazzy weechat api wrapper

  52. qy

    i definitely did not KISS, and as such it got instantly ridiculous