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)
moparisthebesthas joined
moparisthebesthas left
moparisthebesthas joined
Ge0rG
> This server could not prove that it is logs.xmpp.org; its security certificate is from xmpp.org
*sigh*
waqashas left
waqashas joined
Yagizahas left
moparisthebesthas joined
moparisthebesthas joined
freddohas joined
mightyBroccolihas left
benpahas joined
benpahas joined
_purple_bothas joined
_purple_bothas joined
Matthewhas joined
Matthewhas joined
uhoreghas joined
uhoreghas joined
jjrhhas left
Ge0rGhas left
benpahas joined
uhoreghas joined
_purple_bothas joined
Matthewhas joined
lnjhas left
Zashhas left
benpahas joined
_purple_bothas joined
Matthewhas joined
uhoreghas joined
jjrhhas left
jjrhhas left
mightyBroccolihas joined
jjrhhas left
benpahas joined
uhoreghas joined
_purple_bothas joined
Matthewhas joined
lukkechas joined
waqashas left
lukkechas left
lukkechas joined
jjrhhas left
lukkechas left
lukkechas joined
erkanfileshas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
Holgerhas left
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
moparisthebesthas left
moparisthebesthas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
frainzhas left
lukkechas joined
lukkechas left
lukkechas joined
frainzhas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
ralphmhas left
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
redditorhas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
j.rhas joined
Yagizahas joined
krauqhas left
krauqhas joined
mightyBroccolihas left
jjrhhas left
jjrhhas left
!xsf_Martinhas joined
lhas left
mightyBroccolihas joined
pep.has left
lskdjfhas left
Sevehas joined
jjrhhas left
redditorhas left
redditorhas joined
redditorhas left
redditorhas joined
winfriedhas joined
winfriedhas joined
Annhas left
Annhas joined
j.rhas joined
doshas left
UsLhas joined
Lancehas joined
mightyBroccolihas left
Steve Killehas left
Steve Killehas left
mimi89999has joined
mrDoctorWhohas joined
mightyBroccolihas joined
lhas joined
Steve Killehas joined
waqashas joined
lhas left
Alexhas joined
redditorhas left
redditorhas joined
ralphmhas left
Zashhas left
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.
j.rhas joined
lhas joined
mightyBroccolihas left
mightyBroccolihas joined
tahas joined
lhas left
redditorhas left
redditorhas joined
tuxhas joined
krauqhas left
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.
Wiktorhas left
valohas left
valohas joined
Lancehas left
Lancehas joined
Lancehas left
Lancehas joined
erkanfileshas joined
j.rhas joined
j.rhas joined
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
Annhas left
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
tahas left
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.
blackmarkethas joined
tahas left
genofirehas left
blackmarkethas left
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.
tahas left
Wiktor
Yep, but distributing revocations is a problem. That's why OpenPGP has keyservers to make it hard to remove revocations.
tahas joined
genofirehas joined
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
redditorhas joined
waqashas left
Yagizahas left
redditorhas joined
Annhas left
Annhas left
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.
Annhas left
pep.
Yeah I'm also doubtful, even if that's also a property I would like, in the context of e2ee
redditorhas left
redditorhas joined
jonas’has left
j.rhas joined
redditorhas joined
stevenhas left
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
Annhas left
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
krauqhas joined
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
didnt write that for a long time, and it seemd wrong :D
j.rhas joined
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
Half-Shothas left
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
stevenhas left
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.
waqashas joined
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
sezuanhas left
mimi89999has left
Ge0rG
ta: I'm not an endangered person, so I didn't do thorough research.
Half-Shothas joined
vaulorhas joined
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.
mightyBroccolihas left
lorddavidiiihas joined
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.
Tobiashas left
Tobiashas joined
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.
lorddavidiiihas left
lorddavidiiihas joined
tahas left
tuxhas left
lorddavidiiihas left
mightyBroccolihas joined
jjrhhas left
jjrhhas left
oli
so xmpp was a great idea some time ago, but post snowden...
j.rhas joined
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
Half-Shothas left
pep.
We already specified the need in the discussion above. "You don't trust your server"
lorddavidiiihas joined
Guushas left
redditorhas left
lhas joined
lhas joined
j.rhas joined
lorddavidiiihas left
erkanfileshas joined
rionhas joined
lorddavidiiihas joined
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
Alexhas left
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
lhas joined
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