XSF Discussion - 2019-01-01

Same to you, Seve!

Happy new year to you all 🎉🎆

XEPpy new year!

zimpy new year to you, Ge0rG

Happy new year to all

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?

Starting off the new year with a nice little OMEMO discussion :D

that makes not much sense

if you want to do that add another trust state

called Undecided or whatever

but in general i would not advise to add an option to every crazy idea a developer gets

he can implement this on top of the lib

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

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

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

pep.: That's fine, I was still interested in other peoples opinions about that.

Gajim lets you also send a message if you dont trust every device, why not?

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.

that does mean the message is encrypted to THAT device

Syndace, he does not need to circumvent it, your lib does not implement storage or?

lovetox: My lib does it all ^^

Including some trust management.

Syndance: what harm does it do to encrypt untrusted entities? https://tools.ietf.org/html/rfc7435

hm where Syndace dont see it in the code

you have a storage api, you dont implement the backend

so you dont control what gets stored and where

so i can manipulate this on write and on read

your lib never knows whats stored in thedb

Which is essentially circumnventing the trust management, right

and i can implement 10 truststates and save it to the db

Just what I was saying

and on in read i just manipulate it so that i translate it to something that your lib understands

Aure

Sure*

thats not circumventing it in my opinion, i use the api the lib provides

you no where define in what ways i have to use it

but thats splitting hairs

Well you can't use the trust and distrust of the SessionMamager

Which is the official public API to do trusting

Okay so back to the topic. You guys say that it's a good idea to always allow even unauthenticated encryption?

see thats maybe a option, to make that IsThisTrusted method be overwritten by the client

if he wants

are keytransport messages sent only if the contact is trusted?

Yep

see thats where i would want to send maybe a keytransport message even to contacts i have no trust to, or not decided yet

there is no harm in that for the user

and i can answer a prekey message instantly, without asking the user for trust

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

I think this is where the "blind trust before verification" concept comes into play

No Syndace it means something different

bbtv means i trust the client with everything

i just want to establish a session and answerr a prekey message

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

so clients can implement their own concept of what is trusted and what not

yeah, trust management is done on the client

I mean,

I can tell the OMEMO lib whatever I want

The lib keeps the state

lovetox, just making the isTrusted method overwritable doesn't fix the issue I'm afraid

You would need additional info like "this is the first keytransportmessage in response to a prekeymessage"

To allow for complex trust stuff like you described

Syndace, it was not a real code proposal, you know your lib, it just was to describe the concept

Sure I get that

I'm just thinking about how I could make such use-cases possible

hm i would not focus on the example i have given, just how to solve it generic

you lib loads a trust from the db

1. do you expect a certain value here? maybe ints 1, 2, 3?

2. and some where down the line you evaluate what you loaded in your isTrusted()

Yeah but that's the thing, a generic solution must also allow to implement the example you gave.

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

and the client returns True or False

And I don't see how to do that without a ton of information about the whole context of that message/conversation

so pass another info, for what the trust is used

KeyTransport or Message

i mean there is only these 2 or?

but yeah i see it gets more complicated

hm or maybe easier

the client invokes the encryption or not?

maybe it can pass a "ignore_trust=True"

on that one encryption

for the key transport message

Hehe that's what I had before

yeah but then its fine for the example ive given

right.

i can send a message if i really have to

I guess that's the road I have to go down again.

Okay, so now there is a new question

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?

i think we have to define what untrusted means

for me and in gajim

I could allow that *only* for empty KeyTransportMessage used ti do some ratchet forwarding

untrusted means, the user set the state to RED - UNTRUSTED himself via UI

i personally see no reason to encrypt anything to that device ever

but maybe someone has another idea

then i have another state in Gajim, it is orange and means UNDECIDED, i received a message from that unknown device

For me untrusted is everything that is not explicitly trusted. That means undecided also means untrusted.

the user had no time to make a trust decision, or he wants to delay it, because i wants to physically check the fingerprint

and then there is Trusted and blind trust, but it should be the same for the lib

i specifically care about that Undecided state

In the undecided state, does Gajim send encrypted text messages to those devices?

but it would work for me, if i can just pass a ignore_trust=True on the key transport

no, syndace, but it can receive messages

Receiving is a different topic

I allow decryption from untrusted entities

so no, messages are not encrypted to undecided devices

Okay. And I feel like this is the behaviour I see around clients

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.

The other thing is verified vs. unverified.

You speak as a User Holger, and yes i agree because with message you mean text message

but there are protocol messages, where no user data is sent

and i see no problem sending these to undecided devices, there is no harm

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?

lovetox: Right.

i think this is sensibel Syndace

Cool! Thank you :D

From a users perspective I want green - verified yello - unverified red - blocked

so if you don't allow omemo messages, would non-encrypted messages also be blocked?

oli: Non-encrypted stuff is not affected by anything OMEMO

so no

Syndace, is a lib author, he has zero to do with client UI

I just wanted to write that I don't see the reason to refuse sending OMEMO messages to untrusted devices at all.

(if none of the fingerprints of the JID is trusted)

but I realize that you kind of sign the encrypted message.

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

Syndace, maybe thats also a good idea, to write this down in your documentation, what untrusted means in the context of the lib

especially that it doesnt mean "Not Trusted Yet"

aka Undecided

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.

lovetox: Yes agreed, I need some documentation about thst

also we should move this to jdev channel, as this has not much to do with XSF or standards :)

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.

thats what you use verified/unverified states for in my opinion

lovetox: bi

but i cannot send OMEMO messages in undecided state

im not saying that Gajim offers such states

im just saying if i would make this possible i would introduce verified/unverified states

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)

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

to be fair, this MUST/MUST NOT is not sensible because it’s not an interoperability thing, but a policy thing

lovetox‎: sorry, missread you message unverified != undecided

oli, if you refer to conversations

its Daniels client

and Daniel wrote the xep

and its not a standard, its experimental

so if the author feels like it he can change that every day

does xep-0384 reflect what’s actually done on the wire these days?

The XEP should be updated, but i think they work on a bigger overhaul

actually andi is listed as author, didnt know that

Yeah, there's probably going to be a big breakage soon.

That's going to be fun

"soon"

in terms of standard progress :P

Why breakage? With all the X and the namespaces, sholdn't breakage be avoided?

But as long as the cult of OMEMO believes in the evilness of OTR, everything will be fine.

nobody believes OTR is evil

its just not practical for todays messenger needs

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

in the single-client, non-mobile use-case OTR is extremely usable

And there is an OTRv4 in progress since a big moment...

I looked at the streamed talk from CCC. They said no multi-client support, so still terrible for XMPP.

No multi-client and no groupchat

They're introducing PFS though, and using doubleratchet, but this is still not a replacement to OMEMO

(Even if we defined a way not to have all that in <body/>, and how to translate if for transports etc.)

Would work for a whatsapp-like model (besides the group chat)

groupchat is an essential part of whatsapp

so no it would not work at all

But I guess the advantage that they want to have over other mechanisms is that it doesn't require any server nor protocol support

So that's actually a feature for them to use <body/>

Something something trade-off

lovetox: i mean there is no multi client in whatsapp. it seems multi client is not really that important

It is thats why whatsapp trys really hard to fake it

A separate desktop client was always one of the major requests from whatsapp users

then they offered their web thingy, and last time i looked they had a desktop client on mac

i actually dont know if this is real multi device, or if its still proxied over the phone

That goes through the mobile though right?

is this still the case?

I don't know I don't use it

I thought that's how signal did it at least

maybe they solved that problem