jdev - 2022-01-11

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

It doesn't, no

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.

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

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.

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

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

defanor, why just *connected* devices?

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

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

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

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

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

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

*should be the *responsibility* of the sending entity

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.

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

(in an ideal world that is)

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.

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

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

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

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.

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

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

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

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.

« 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

of course, it's a bandaid

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

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

I guess Snikket can do that because it's Snikket

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

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

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

That's up to you 🙂

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

If you publish keys.... pretty much yes

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

That's in theory, and in some threat model

no, that's what happens in practice ;)

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

Or maybe in Snikket

and you can't control what clients other people use

so it's what happens in practice :)

Practice is a mix of all this

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

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

having to write a snazzy weechat api wrapper

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