-
Guus
Same to you, Seve!
-
edhelas
Happy new year to you all 🎉🎆
-
Ge0rG
XEPpy new year!
-
mathieui
zimpy new year to you, Ge0rG
-
Neustradamus
Happy new year to all
-
Syndace
It 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?
-
Syndace
Starting off the new year with a nice little OMEMO discussion :D
-
lovetox
that makes not much sense
-
lovetox
if you want to do that add another trust state
-
lovetox
called Undecided or whatever
-
lovetox
but in general i would not advise to add an option to every crazy idea a developer gets
-
lovetox
he can implement this on top of the lib
-
lovetox
in 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
-
Syndace
pep.: That's fine, I was still interested in other peoples opinions about that.
-
lovetox
Gajim lets you also send a message if you dont trust every device, why not?
-
Syndace
lovetox: 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.
-
lovetox
that does mean the message is encrypted to THAT device
-
lovetox
Syndace, he does not need to circumvent it, your lib does not implement storage or?
-
Syndace
lovetox: My lib does it all ^^
-
Syndace
Including some trust management.
-
oli
Syndance: what harm does it do to encrypt untrusted entities? https://tools.ietf.org/html/rfc7435
-
lovetox
hm where Syndace dont see it in the code
-
lovetox
you have a storage api, you dont implement the backend
-
lovetox
so you dont control what gets stored and where
-
lovetox
so i can manipulate this on write and on read
-
lovetox
your lib never knows whats stored in thedb
-
Syndace
Which is essentially circumnventing the trust management, right
-
lovetox
and i can implement 10 truststates and save it to the db
-
Syndace
Just what I was saying
-
lovetox
and on in read i just manipulate it so that i translate it to something that your lib understands
-
Syndace
Aure
-
Syndace
Sure*
-
lovetox
thats not circumventing it in my opinion, i use the api the lib provides
-
lovetox
you no where define in what ways i have to use it
-
lovetox
but thats splitting hairs
-
Syndace
Well you can't use the trust and distrust of the SessionMamager
-
Syndace
Which is the official public API to do trusting
-
Syndace
Okay so back to the topic. You guys say that it's a good idea to always allow even unauthenticated encryption?
-
lovetox
see thats maybe a option, to make that IsThisTrusted method be overwritten by the client
-
lovetox
if he wants
-
lovetox
are keytransport messages sent only if the contact is trusted?
-
Syndace
Yep
-
lovetox
see thats where i would want to send maybe a keytransport message even to contacts i have no trust to, or not decided yet
-
lovetox
there is no harm in that for the user
-
lovetox
and 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
-
Syndace
I think this is where the "blind trust before verification" concept comes into play
-
lovetox
No Syndace it means something different
-
lovetox
bbtv means i trust the client with everything
-
lovetox
i just want to establish a session and answerr a prekey message
-
lovetox
either 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
-
lovetox
so clients can implement their own concept of what is trusted and what not
-
pep.
yeah, trust management is done on the client
-
pep.
I mean,
-
pep.
I can tell the OMEMO lib whatever I want
-
pep.
The lib keeps the state
-
Syndace
lovetox, just making the isTrusted method overwritable doesn't fix the issue I'm afraid
-
Syndace
You would need additional info like "this is the first keytransportmessage in response to a prekeymessage"
-
Syndace
To allow for complex trust stuff like you described
-
lovetox
Syndace, it was not a real code proposal, you know your lib, it just was to describe the concept
-
Syndace
Sure I get that
-
Syndace
I'm just thinking about how I could make such use-cases possible
-
lovetox
hm i would not focus on the example i have given, just how to solve it generic
-
lovetox
you lib loads a trust from the db
-
lovetox
1. do you expect a certain value here? maybe ints 1, 2, 3?
-
lovetox
2. and some where down the line you evaluate what you loaded in your isTrusted()
-
Syndace
Yeah but that's the thing, a generic solution must also allow to implement the example you gave.
-
lovetox
so 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
-
lovetox
and the client returns True or False
-
Syndace
And I don't see how to do that without a ton of information about the whole context of that message/conversation
-
lovetox
so pass another info, for what the trust is used
-
lovetox
KeyTransport or Message
-
lovetox
i mean there is only these 2 or?
-
lovetox
but yeah i see it gets more complicated
-
lovetox
hm or maybe easier
-
lovetox
the client invokes the encryption or not?
-
lovetox
maybe it can pass a "ignore_trust=True"
-
lovetox
on that one encryption
-
lovetox
for the key transport message
-
Syndace
Hehe that's what I had before
-
lovetox
yeah but then its fine for the example ive given
-
Syndace
right.
-
lovetox
i can send a message if i really have to
-
Syndace
I guess that's the road I have to go down again.
-
Syndace
Okay, so now there is a new question
-
Syndace
Let'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?
-
lovetox
i think we have to define what untrusted means
-
lovetox
for me and in gajim
-
Syndace
I could allow that *only* for empty KeyTransportMessage used ti do some ratchet forwarding
-
lovetox
untrusted means, the user set the state to RED - UNTRUSTED himself via UI
-
lovetox
i personally see no reason to encrypt anything to that device ever
-
lovetox
but maybe someone has another idea
-
lovetox
then i have another state in Gajim, it is orange and means UNDECIDED, i received a message from that unknown device
-
Syndace
For me untrusted is everything that is not explicitly trusted. That means undecided also means untrusted.
-
lovetox
the user had no time to make a trust decision, or he wants to delay it, because i wants to physically check the fingerprint
-
lovetox
and then there is Trusted and blind trust, but it should be the same for the lib
-
lovetox
i specifically care about that Undecided state
-
Syndace
In the undecided state, does Gajim send encrypted text messages to those devices?
-
lovetox
but it would work for me, if i can just pass a ignore_trust=True on the key transport
-
lovetox
no, syndace, but it can receive messages
-
Syndace
Receiving is a different topic
-
Syndace
I allow decryption from untrusted entities
-
lovetox
so no, messages are not encrypted to undecided devices
-
Syndace
Okay. And I feel like this is the behaviour I see around clients
-
Holger
I 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.
-
Holger
The other thing is verified vs. unverified.
-
lovetox
You speak as a User Holger, and yes i agree because with message you mean text message
-
lovetox
but there are protocol messages, where no user data is sent
-
lovetox
and i see no problem sending these to undecided devices, there is no harm
-
Syndace
So 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?
-
Holger
lovetox: Right.
-
lovetox
i think this is sensibel Syndace
-
Syndace
Cool! Thank you :D
-
oli
From a users perspective I want green - verified yello - unverified red - blocked
-
oli
so if you don't allow omemo messages, would non-encrypted messages also be blocked?
-
Syndace
oli: Non-encrypted stuff is not affected by anything OMEMO
-
Syndace
so no
-
lovetox
Syndace, is a lib author, he has zero to do with client UI
-
oli
I 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)
-
oli
but I realize that you kind of sign the encrypted message.
-
lovetox
we 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
-
lovetox
Syndace, maybe thats also a good idea, to write this down in your documentation, what untrusted means in the context of the lib
-
lovetox
especially that it doesnt mean "Not Trusted Yet"
-
lovetox
aka Undecided
-
Syndace
oli: 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.
-
Syndace
lovetox: Yes agreed, I need some documentation about thst
-
lovetox
also we should move this to jdev channel, as this has not much to do with XSF or standards :)
-
oli
For 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.
-
lovetox
thats what you use verified/unverified states for in my opinion
-
oli
lovetox: bi
-
oli
but i cannot send OMEMO messages in undecided state
-
lovetox
im not saying that Gajim offers such states
-
lovetox
im just saying if i would make this possible i would introduce verified/unverified states
-
oli
I 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
-
oli
lovetox‎: sorry, missread you message unverified != undecided
-
lovetox
oli, if you refer to conversations
-
lovetox
its Daniels client
-
lovetox
and Daniel wrote the xep
-
lovetox
and its not a standard, its experimental
-
lovetox
so 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?
-
lovetox
The XEP should be updated, but i think they work on a bigger overhaul
-
lovetox
actually 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
-
jonas’
"soon"
-
pep.
in terms of standard progress :P
-
oli
Why breakage? With all the X and the namespaces, sholdn't breakage be avoided?
-
oli
But as long as the cult of OMEMO believes in the evilness of OTR, everything will be fine.
-
jonas’
nobody believes OTR is evil
-
lovetox
its just not practical for todays messenger needs
-
lovetox
xmpp 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
-
Neustradamus
And there is an OTRv4 in progress since a big moment...
-
Zash
I 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.)
-
oli
Would work for a whatsapp-like model (besides the group chat)
-
lovetox
groupchat is an essential part of whatsapp
-
lovetox
so 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/>
-
Zash
Something something trade-off
-
oli
lovetox: i mean there is no multi client in whatsapp. it seems multi client is not really that important
-
lovetox
It is thats why whatsapp trys really hard to fake it
-
lovetox
A separate desktop client was always one of the major requests from whatsapp users
-
lovetox
then they offered their web thingy, and last time i looked they had a desktop client on mac
-
lovetox
i actually dont know if this is real multi device, or if its still proxied over the phone
-
pep.
That goes through the mobile though right?
-
lovetox
is this still the case?
-
pep.
I don't know I don't use it
-
pep.
I thought that's how signal did it at least
-
lovetox
maybe they solved that problem