SyndaceIt seems like some clients allow sending OMEMO encrypted messages even to untrusted entities. I'm not sure whether I want to allow that in my library. Any pros/cons?
SyndaceStarting off the new year with a nice little OMEMO discussion :D
lovetoxthat makes not much sense
lovetoxif you want to do that add another trust state
lovetoxcalled Undecided or whatever
lovetoxbut in general i would not advise to add an option to every crazy idea a developer gets
lovetoxhe can implement this on top of the lib
lovetoxin my opinion the lib should only know, should i prevent sending this or not, True or False, and this info should be supplied by the client depending on the context
pep.I have wrongly fed Syndace with false information. I thought Conversations was allowing that, but no it does force me to trust before sending. I have "Blind Trust Before Verification" unchecked, I don't know if that happens in general
pep.lovetox, "if you want to do that add another trust state", this is only possible in the client, not in the OMEMO lib, maybe in the XMPP lib
Syndacepep.: That's fine, I was still interested in other peoples opinions about that.
lovetoxGajim lets you also send a message if you dont trust every device, why not?
Syndacelovetox: Thanks, that's exactly what I thought. If someone really wants to allow that, he can circumvent my libs trust management and create his own.
lovetoxthat does mean the message is encrypted to THAT device
lovetoxSyndace, he does not need to circumvent it, your lib does not implement storage or?
Syndacelovetox: My lib does it all ^^
SyndaceIncluding some trust management.
oliSyndance: what harm does it do to encrypt untrusted entities? https://tools.ietf.org/html/rfc7435
lovetoxhm where Syndace dont see it in the code
lovetoxyou have a storage api, you dont implement the backend
lovetoxso you dont control what gets stored and where
lovetoxso i can manipulate this on write and on read
lovetoxyour lib never knows whats stored in thedb
SyndaceWhich is essentially circumnventing the trust management, right
lovetoxand i can implement 10 truststates and save it to the db
SyndaceJust what I was saying
lovetoxand on in read i just manipulate it so that i translate it to something that your lib understands
lovetoxthats not circumventing it in my opinion, i use the api the lib provides
lovetoxyou no where define in what ways i have to use it
lovetoxbut thats splitting hairs
SyndaceWell you can't use the trust and distrust of the SessionMamager
SyndaceWhich is the official public API to do trusting
SyndaceOkay so back to the topic. You guys say that it's a good idea to always allow even unauthenticated encryption?
lovetoxsee thats maybe a option, to make that IsThisTrusted method be overwritten by the client
lovetoxif he wants
lovetoxare keytransport messages sent only if the contact is trusted?
lovetoxsee thats where i would want to send maybe a keytransport message even to contacts i have no trust to, or not decided yet
lovetoxthere is no harm in that for the user
lovetoxand i can answer a prekey message instantly, without asking the user for trust
pep.Ok so in reality it's not "sending to an unstrusted device", it's the client that tells the OMEMO lib "I trust this device", even in an "undecided" state
SyndaceI think this is where the "blind trust before verification" concept comes into play
lovetoxNo Syndace it means something different
lovetoxbbtv means i trust the client with everything
lovetoxi just want to establish a session and answerr a prekey message
lovetoxeither way, to answer your question as you see, clients want to do different things, so maybe your isTrusted() method, should be able to be overwritten
lovetoxso clients can implement their own concept of what is trusted and what not
pep.yeah, trust management is done on the client
pep.I can tell the OMEMO lib whatever I want
pep.The lib keeps the state
Syndacelovetox, just making the isTrusted method overwritable doesn't fix the issue I'm afraid
SyndaceYou would need additional info like "this is the first keytransportmessage in response to a prekeymessage"
SyndaceTo allow for complex trust stuff like you described
lovetoxSyndace, it was not a real code proposal, you know your lib, it just was to describe the concept
SyndaceSure I get that
SyndaceI'm just thinking about how I could make such use-cases possible
lovetoxhm i would not focus on the example i have given, just how to solve it generic
lovetoxyou lib loads a trust from the db
lovetox1. do you expect a certain value here? maybe ints 1, 2, 3?
lovetox2. and some where down the line you evaluate what you loaded in your isTrusted()
SyndaceYeah but that's the thing, a generic solution must also allow to implement the example you gave.
lovetoxso why not pass what was loaded from the db (which could be anything you dont have to care) to the client in a isTrusted() call
lovetoxand the client returns True or False
SyndaceAnd I don't see how to do that without a ton of information about the whole context of that message/conversation
lovetoxso pass another info, for what the trust is used
lovetoxKeyTransport or Message
lovetoxi mean there is only these 2 or?
lovetoxbut yeah i see it gets more complicated
lovetoxhm or maybe easier
lovetoxthe client invokes the encryption or not?
lovetoxmaybe it can pass a "ignore_trust=True"
lovetoxon that one encryption
lovetoxfor the key transport message
SyndaceHehe that's what I had before
lovetoxyeah but then its fine for the example ive given
lovetoxi can send a message if i really have to
SyndaceI guess that's the road I have to go down again.
SyndaceOkay, so now there is a new question
SyndaceLet's only look at messages, that have actual content. A text message and not an empty KeyTransportMessage. Is there any reason to allow sending such messages to untrusted entities?
lovetoxi think we have to define what untrusted means
lovetoxfor me and in gajim
SyndaceI could allow that *only* for empty KeyTransportMessage used ti do some ratchet forwarding
lovetoxuntrusted means, the user set the state to RED - UNTRUSTED himself via UI
lovetoxi personally see no reason to encrypt anything to that device ever
lovetoxbut maybe someone has another idea
lovetoxthen i have another state in Gajim, it is orange and means UNDECIDED, i received a message from that unknown device
SyndaceFor me untrusted is everything that is not explicitly trusted. That means undecided also means untrusted.
lovetoxthe user had no time to make a trust decision, or he wants to delay it, because i wants to physically check the fingerprint
lovetoxand then there is Trusted and blind trust, but it should be the same for the lib
lovetoxi specifically care about that Undecided state
SyndaceIn the undecided state, does Gajim send encrypted text messages to those devices?
lovetoxbut it would work for me, if i can just pass a ignore_trust=True on the key transport
lovetoxno, syndace, but it can receive messages
SyndaceReceiving is a different topic
SyndaceI allow decryption from untrusted entities
lovetoxso no, messages are not encrypted to undecided devices
SyndaceOkay. And I feel like this is the behaviour I see around clients
HolgerI think 'trusted' devices should be those I send messages to. So there's no 'undecided' state here. I either send or send not messages to a device.
HolgerThe other thing is verified vs. unverified.
lovetoxYou speak as a User Holger, and yes i agree because with message you mean text message
lovetoxbut there are protocol messages, where no user data is sent
lovetoxand i see no problem sending these to undecided devices, there is no harm
SyndaceSo can we agree that empty KeyTransportMessages should be available no matter the trust status and everything else (with actual content) is only available if you explicitly trust?
lovetoxi think this is sensibel Syndace
SyndaceCool! Thank you :D
oliFrom a users perspective I want
green - verified
yello - unverified
red - blocked
oliso if you don't allow omemo messages, would non-encrypted messages also be blocked?
Syndaceoli: Non-encrypted stuff is not affected by anything OMEMO
lovetoxSyndace, is a lib author, he has zero to do with client UI
oliI just wanted to write that I don't see the reason to refuse sending OMEMO messages to untrusted devices at all.
oli(if none of the fingerprints of the JID is trusted)
olibut I realize that you kind of sign the encrypted message.
lovetoxwe have to take care what the terms mean, untrusted means for you, you didnt trust but also not block, but in Gajim untrusted means blocked
lovetoxSyndace, maybe thats also a good idea, to write this down in your documentation, what untrusted means in the context of the lib
lovetoxespecially that it doesnt mean "Not Trusted Yet"
Syndaceoli: I understand what you mean, I had a little read on the RFC you linked. I think that BTBV is basically the TOFU described in that RFC. But I don't think it is the job of my library to do that, but a per-client choice to go with that behaviour.
Syndacelovetox: Yes agreed, I need some documentation about thst
lovetoxalso we should move this to jdev channel, as this has not much to do with XSF or standards :)
oliFor Gajim: I think it would be nice to be able to have en encyrypted chat even with an "Not Decided" fingerprint. This gives users the opportunity to really check the fingerprint. If you prevent encryption in undecided state, users just click trusted to be able to chat.
lovetoxthats what you use verified/unverified states for in my opinion
olibut i cannot send OMEMO messages in undecided state
lovetoxim not saying that Gajim offers such states
lovetoxim just saying if i would make this possible i would introduce verified/unverified states
oliI feel this has to do XEP-0384:
"Clients MUST NOT use a newly built session to transmit data without user intervention. If a client were to opportunistically start using sessions for sending without asking the user whether to trust a device first, an attacker could publish a fake device for this user, which would then receive copies of all messages sent by/to this user."
The most popular mobile client just gives a shit about this (in the default configuration)
pep.Yes that's something I also dislike in conversations, that it forces me to trust before sending (with btbv unchecked, dunno about other states), even though I didn't actually verify the fingerprint
jonas’to be fair, this MUST/MUST NOT is not sensible because it’s not an interoperability thing, but a policy thing
olilovetox: sorry, missread you message unverified != undecided
lovetoxoli, if you refer to conversations
lovetoxits Daniels client
lovetoxand Daniel wrote the xep
lovetoxand its not a standard, its experimental
lovetoxso if the author feels like it he can change that every day
jonas’does xep-0384 reflect what’s actually done on the wire these days?
lovetoxThe XEP should be updated, but i think they work on a bigger overhaul
lovetoxactually andi is listed as author, didnt know that
pep.Yeah, there's probably going to be a big breakage soon.
pep.That's going to be fun
pep.in terms of standard progress :P
oliWhy breakage? With all the X and the namespaces, sholdn't breakage be avoided?
oliBut as long as the cult of OMEMO believes in the evilness of OTR, everything will be fine.
jonas’nobody believes OTR is evil
lovetoxits just not practical for todays messenger needs
lovetoxxmpp clients have mostly a big usability deficit, and everything that cant be made really stable/easy/usable for users, i would right now not invest my time into
jonas’in the single-client, non-mobile use-case OTR is extremely usable
NeustradamusAnd there is an OTRv4 in progress since a big moment...
ZashI looked at the streamed talk from CCC. They said no multi-client support, so still terrible for XMPP.
pep.No multi-client and no groupchat
pep.They're introducing PFS though, and using doubleratchet, but this is still not a replacement to OMEMO
pep.(Even if we defined a way not to have all that in <body/>, and how to translate if for transports etc.)
oliWould work for a whatsapp-like model (besides the group chat)
lovetoxgroupchat is an essential part of whatsapp
lovetoxso no it would not work at all
pep.But I guess the advantage that they want to have over other mechanisms is that it doesn't require any server nor protocol support
pep.So that's actually a feature for them to use <body/>
ZashSomething something trade-off
olilovetox: i mean there is no multi client in whatsapp. it seems multi client is not really that important
lovetoxIt is thats why whatsapp trys really hard to fake it
lovetoxA separate desktop client was always one of the major requests from whatsapp users
lovetoxthen they offered their web thingy, and last time i looked they had a desktop client on mac
lovetoxi actually dont know if this is real multi device, or if its still proxied over the phone