-
erkanfiles
ralphm: I just finished the minutes for 2018-12-20... Could you check this before I submit? This is my first try...
-
erkanfiles
Or anybody else?
-
Ge0rG
erkanfiles: I can review as well if you wish. You need somebody to forward them to the lists anyway.
-
Ge0rG
(I'm not on board, but on members)
-
Ge0rG
> This server could not prove that it is logs.xmpp.org; its security certificate is from xmpp.org *sigh*
-
pep.
https://wiki.xmpp.org/web/Main_Page somebody added "Quickstart for developers" on the main page, but it points nowhere. There's also "Modern Login Procedure" that points nowhere. Even if that can be a good idea I vote to remove them while they're empty.
-
Syndace
We had a discussion about OMEMO key cross-signing and without giving any further context it seems like revocation is the biggest problem which needs some smart ideas. If we do it the GPG-way we need some sort of revocation-cert. The problem is where to upload the revocation cert to, because a malicious admin could block uploading those or remove them from PEP/whatever.
-
Wiktor
Syndace, why is cross signing intermixed with revocations? As far as I understand cross signing is for extending trust to new keys. If the device is not used for some time it's "revoked" automatically in current design already. That'd cover common scenarios like device migration.
-
Syndace
What do you mean by "current design"?
-
Syndace
Revocation is for when you loose a device or you know the keys have been compromised.
-
Wiktor
I mean by what Conversations do hehe, if you lose a device then after some time the client will stop encrypting for that decide
-
Wiktor
Device*
-
Syndace
Okay, that does not use cross-signing though ^^
-
Wiktor
Yes but it's already working for "revocations" so no need to invent anything new here
-
Wiktor
Just keep the same rules for cross signed devices, no need for extra revocations
-
Syndace
I'm sorry but those are two completely different things. One is publishing cryptographic signatures to tell others that you trust a certain key and the other is some client-side timeout logic that is not specified or cryptographically backed at all
-
Wiktor
I'd keep it lightweight, like in Matrix, the cross signing signature should be created by already trusted device and add trust only once, then the trusted device should be treated like any other.
-
Wiktor
If not you risk reimplemening OpenPGP and that's a lot of stuff.
-
Syndace
Yes that's the goal. The thing is that revocation cannot be ignored really. You need a mechanism to tell people that a key is not trustworthy any more. Otherwise an attacker could use compromised keys to cross-sign as many malicious devices as he likes to.
-
Wiktor
Yep, but distributing revocations is a problem. That's why OpenPGP has keyservers to make it hard to remove revocations.
-
Wiktor
Actually I had an idea how to use OpenPGP (on Android through OpenKeychain) to distribute trusted devices set. But that's including OpenPGP in the solution...
-
pep.
Wiktor, if you implement a way to say "I trust this device" to others, you will also need a way to say "I don't trust this device anymore", I don't think there's any need for arguing that one is not needed
-
pep.
And indeed that can be easily blocked by the server
-
Wiktor
And all that has already been solved by OpenPGP, I just warn that there is a risk of reimplemening square wheel here
-
pep.
That point is clear. That's not what I was replying to
-
pep.
You talked about Matrix, do you have any insight on how they handle this?
-
Wiktor
OpenPGP also has signature expiry, you can use that to automatically expire signatures and require re signing if the device is used
-
Wiktor
Nope, I'm not involved in Matrix that much, the blog post I read only mentioned cross signing by already trusted devices
-
pep.
Right, I read that one as well
-
uhoreg
The (work-in-progress) proposal for cross-signing in Matrix is at https://github.com/matrix-org/matrix-doc/pull/1756, which uses a master key for signing device keys, rather than having devices sign each other and trying to navigate an arbitrary trust graph. And rather than revocations, we're just nuking the master key and replacing it with a new one.
-
uhoreg
It does depend on the server being somewhat trustworthy, but I don't think there's much you can do about it.
-
Syndace
Trusting the server is not acceptable for OMEMO I'd say.
-
uhoreg
If you can figure out a way to do it without having to trust the server to distribute things properly, I'd be very interested in seeing it. It would be very desirable to have that property, but I haven't been able to figure it out yet.
-
pep.
Yeah I'm also doubtful, even if that's also a property I would like, in the context of e2ee
-
lovetox
also omemo is relying on the server already
-
pep.
Yes it is. A server can just refuse publishing keys
-
lovetox
if you remove a device from your devicelist, to broadcast to others that its not in use anymore
-
lovetox
then this could be just not broadcasted, and other contacts will never know that you dont use the device anymore
-
Syndace
It is relying on the server but the only thing the server can do is block OMEMO overall or attempt to MITM.
-
lovetox
no as i just described
-
Syndace
Or that, righr
-
lovetox
it can block "revocation" of devices
-
jonas’
the only use of which would be to attempt MITM, right?
-
lovetox
you cant MITM omemo
-
lovetox
its simply not possible as of to date
-
Syndace
well if the admin got hands on one of your devices it would make sense for him to block the unpublishing
-
lovetox
but you can steal a device
-
Syndace
why is it not
-
lovetox
and then block that this device is revoked
-
lovetox
but thats not MITM
-
pep.
lovetox, you can mitm? and it can easily _not_ be detected, (who even reads the list of fingerprints)
-
pep.
Ah hmm
-
pep.
Not MITM
-
pep.
Add yourself in the device list
-
jonas’
yeah, you’re not in the middle, but ... I’d still call this mitm
-
lovetox
sorry if you dont verify the fingerprint, then its also not a MITM attack, its a I hope this user doesnt know what he does attack
-
jonas’
the effects (can read and inject(?) messages) and the mitigations (validate your bloody fingerprints) are the same
-
pep.
jonas’, inject yes, the original account doesn't even have to know
-
pep.
If OMEMO is based on the fact that the server is not trusted, this is pretty much a fail
-
lovetox
pep., i cant agree with you on that
-
lovetox
you seem to think you can just add a device and then everyone is starting to encrypt all his messages to that
-
pep.
Because it's not true?
-
lovetox
this is simply not possible if you configure your client correctly
-
lovetox
you cant with Gajim
-
pep.
Right, you have a big assumption right there
-
lovetox
there will be a popup that tells you, NEW DEVICE do you want to trust?
-
lovetox
otherwise it will never encrypt to that device
-
lovetox
there is no attack as a malicious server, that does not depend on the user actively ignoring to verify fingerprints
-
jonas’
lovetox, and the average user will just accept
-
lovetox
but thats true for every encryption
-
pep.
Yes
-
lovetox
this has nothing to do with omemo
-
pep.
Well, yes and no. It has to do how it's designed, and what type of users it's targetting
-
pep.
People come to us saying "OMEMO is the #1 feature I want. I don't consider a client otherwise" and they don't understand what it means
-
lovetox
I could easily write a client that encrypts only to QR code scanned devices
-
lovetox
then every device is physically verified
-
lovetox
this is a client UI decision, and is not a fail in the protocol
-
pep.
True, you could. I doubt you'd manage to market that
-
lovetox
yeah of course, lets make compromises, because the thread model is not NSA prove
-
lovetox
the thread model is, lets encrypt 99% of my data in a way that 99% of people cant decrypt it
-
lovetox
*profe✎ -
pep.
proof :)
-
lovetox
*proof ✏
-
lovetox
damn it
-
lovetox
didnt write that for a long time, and it seemd wrong :D
-
lovetox
no im all for looking into this stuff, but signal protocol or whatever you want to call it, is pretty pretty good
-
lovetox
there is really not much left to make better
-
Ge0rG
> lets encrypt 99% of my data in a way that 99% of people cant decrypt it I don't want 99% of people to decrypt my data! Only a selected subset of a few persons!
-
Ge0rG
the challenge is to build a usable client around the signal protocol.
-
Ge0rG
actually, no. The challenge is to build a usable client around any encryption primitive.
-
lovetox
i agree thats the challenge
-
Ge0rG
I think that OpenPGP has better UX than OMEMO, and Matrix seems to agree. A per-account master key that is the root of all trust for a user is so much more transparent and usable than N device keys on your side and M device keys on each of your contact's side with NxM trust relationships
-
Ge0rG
But what do I know.
-
lovetox
and in my opinion what we have now, specially in Gajim there is lots of room for improvement before i go and criticise the protocol
-
Ge0rG
if the protocol did it right, you wouldn't have a forest of possible fuckups to solve in your client.
-
lovetox
Ge0rG, i also wrote a already usable openpgp plugin for the current Gajim version, works fine, i didnt impl the secret key transfer yet
-
lovetox
and you can also make openpgp hard to use
-
pep.
lovetox, I just tested with conversations and dino, none tell me I've added a new device
-
Ge0rG
But we only ever specify the wire format, no need to tell developers how to solve the really complicated UX problems.
-
pep.
So I guess that's already a nice set of users not checking
-
lovetox
pep., because blind trust is activated in C by default maybe?
-
Ge0rG
Except that for encryption, a UX fail might kill people.
-
pep.
lovetox, of course it is
-
pep.
That's the whole point of Conversations
-
lovetox
to actually have conversations :D
-
lovetox
not care about encryption
-
pep.
I disagree here
-
lovetox
i agree with that to be honest, lets concentrate less about that crypto mania and more about usable clients
-
Ge0rG
Let's not implement OMEMO.
-
pep.
mod_omemo_mitm when
-
pep.
Just to prove a point
-
Ge0rG
If you are a political dissident, don't use xmpp. It will get you killed.
-
Ge0rG
Also there is no strong binding between the JID and the keys, so OMEMO ends up being an encryption overlay with opaque rules (superset of device IDs of all the participant JIDs) on top of a message routing overlay with opaque rules on top of a federated client - server - server - client overlay on top of TCP IP
-
ta
Ge0rG: just out of couriosity, what's your recommendation for endangered persons?
-
Ge0rG
ta: depends on who's after you. NSA - don't use Smartphones. Russians - don't use Telegram. Other countries - use Apple devices and Signal with a burner number from an American VoIP service
-
Ge0rG
ta: I'm not an endangered person, so I didn't do thorough research.
-
pep.
Tbh I understand the "privacy by default" bits and I agree with that. I would want to reach a level where people still have some margin to do their research when they suspect they're being targeted. Atm it's probably to late when you reach this conclusion
-
ta
Mw neither, but i am interested in that topic. To secure your privacy yoi almost have to act like a "wanted" person.
-
ta
I am aware that XMPP is not ideal for that matter either.
-
pep.
I don't think any solution out there is tbh, you can use bits and pieces of some solutions, but the most effective one is certainly to act as a commoner
-
ta
And configuring mobile devices to leak as little information as possible is a fight against windmills.
-
ta
I can not act like most commoners, i don't want to use closed Software (dont get me started on hardware, its a pity). So i always stand out of the masses. That's why i like to encrypt stuff. Since i would stand out my bitstreams sourroubding me shall not be plaintext. Like i dont run around with Information about me printed on my clothes.
-
ta
Some real p2p solution routed through some onion protocol, verified only in person and used on fully encrypted devices with plausible deniabillity is probably the safest way to not leak content of your Conversation, but will be obvious as hell to agencies.
-
oli
so xmpp was a great idea some time ago, but post snowden...
-
pep.
Because pre-Snowden wasn't as bad?
-
oli
for irc like groups use matrix. for one to one use something p2p
-
pep.
I'd be interested to know if matrix actually helps here, or if it's more or less the same issues and you have to trust the server somewhat
-
pep.
hint: I don't think it changes much
-
ta
Depends on your needs
-
pep.
We already specified the need in the discussion above. "You don't trust your server"
-
rion
Hi. I'm looking at "6.3 Stream Feature" of caps xep. It's nice. But is there something similar for services list (disco#items) and their versions? I mean I'd like to cache not just jabber.ru but conference.jabber.ru, upload.jabber.ru and other services of my server.
-
lovetox
but how do you get the info about the version of the disco items?
-
lovetox
with normal contacts, we exchange presence and we have to do this anyway so we add the version there and save a query
-
lovetox
but you exchange nothing with a MUC or component where you could add the version and save the query
-
lovetox
the first every contact is the disco query, so you get to know what that thing is in the first place
-
rion
lovetox: no idea how to do this properly. for example if caps computation of jabber.ru would also include conference.jabber.ru that would be enough for me.
-
lovetox
to answer your question, no we dont have something like that for server components
-
rion
btw about muc. ejabberd already can compute caps for it and send them early on join.
-
lovetox
thats too late
-
lovetox
you have to know if a jid is a muc before you join
-
rion
well yes. but it's better than nothing
-
rion
is there a place where I can write my wishes for xep improvements?
-
lovetox
hm its only useful if you dont use MAM
-
lovetox
yes the standards mailing list
-
lovetox
standards@xmpp.org
-
lovetox
oh rion i spoke too soon
-
lovetox
there is an experimental xep who does what you want i think
-
lovetox
at least in part
-
lovetox
https://xmpp.org/extensions/xep-0390.html#usecases-stream-feature
-
rion
390?
-
lovetox
thats would be also the place to comment for improvements because its experimental
-
lovetox
115 will never change
-
lovetox
also for the MUC case there is another problem
-
lovetox
the MUC component has caps but they are not that useful
-
lovetox
because every MUC jid itself can have different caps
-
rion
interesting
-
lovetox
yeah but also here again, server caps yeah nice
-
lovetox
but what you even more need are your account caps
-
rion
well I just sent the email about xep-0390 updates. I hope it's not lost since I don't have any notifications about its destiny :)
-
lovetox
yeah takes some minutes until it shows up
-
lovetox
you registered on the list though?
-
rion
nope..
-
lovetox
em yeah i maybe should have mentioned that ^^^^
-
lovetox
dont know if it allows to post for unregistered users
-
lovetox
https://mail.jabber.org/mailman/listinfo/standards
-
rion
should I send "register" or something ?
-
rion
ok
-
lovetox
hm rion no mom
-
lovetox
seems you dont need to register
-
lovetox
the registration is for subscribing
-
lovetox
here you can look if it is posted
-
lovetox
https://mail.jabber.org/pipermail/standards/
-
lovetox
ah damn rion
-
lovetox
it says it
-
lovetox
Note: To cut down on spam, you must be subscribed to this list in order to post!
-
rion
I see. I'll resend :)
-
rion
just subscribed
-
rion
it's there now
-
lovetox
gratz on your first post :D
-
rion
=))