18:38:57 lovetox> one could do it that way, but then you would have to check from time to time, if your db stored prekeys are really the ones that are published
you have to do that anyways because PEP services tend to "forget" your stuff from time to time
Guushas left
Guushas joined
Guushas left
Guushas joined
Martinhas left
mrdoctorwhohas joined
Guushas left
Guushas joined
lnjhas joined
kasper.dementhas joined
kasper.dementhas joined
karphas left
karphas joined
kasper.dementhas left
mikaelahas joined
Dave Cridlandhas left
Dave Cridlandhas joined
rishiraj22has left
Dave Cridlandhas left
Dave Cridlandhas joined
kasper.dementhas joined
labdsfhas left
Guushas left
Guushas joined
alacerhas joined
Guushas left
Guushas joined
Ge0rG
Isn't it awesome how the xmpp and OMEMO identity models extend each other?
jonasw
I sense sarcasm
kasper.dementhas joined
rishiraj22has left
Guus
Ge0rG, sarcasme? Nahhh...
la|r|mahas joined
Guusraises fist to autocorrect.
lskdjfhas joined
flow
Ge0rG, while it's trivial to change that?
Dave Cridlandhas left
Dave Cridlandhas joined
kasper.dementhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Martinhas left
Ge0rG
flow: one of the strong opinions that I hold is: if you want cryptographic identities, you should have a protocol using those as a first-level citizen, not tacked upon another routing protocol
labdsfhas joined
marchas joined
labdsfhas left
labdsfhas joined
flow
Ge0rG, I know. But what do you suggest an xmpp based e2ee protocol should do? Using the public key as one's JID localpart?
mikaelahas left
Guushas left
Guushas joined
moparisthebesthas joined
Ge0rG
flow: I think there needs to be a stronger cryptographic link between the user identity, the key material and the JID.
Ge0rG
flow: if I was doing things, I'd go with user keys that contain a signature of the JID, plus maybe an S/MIME like CA system
flow
"signature of the JID"?
flow
or a signed statement of the user's JID?
mikaelahas joined
Ge0rG
The latter.
flow
I'm also not sure how that prove ownership of the JID
Ge0rG
It doesn't. But it means you can't move a key to a different JID
flow
And preventing that is desirable because?
Nekithas left
Nekithas joined
marchas left
Guushas left
Guushas joined
Ge0rG
flow: I'm not sure. It's just a bad gut feeling, nothing specific. Maybe abuse of sloppy implementations leading to impersonation of other users...
labdsfhas left
labdsfhas joined
rionhas left
404.cityhas joined
flow
Ge0rG, So if you would be designing things, the main difference would be an additional signed statement of the JID and that only because of a gut feeling that it would possibly beneficial. Or did I miss something?
kasper.dementhas joined
Guushas left
Guushas joined
Steve Killehas left
Steve Killehas left
Ge0rG
flow: the main difference is: I would go with a two or three layer architecture. A user has their identity key (or primary device key), and signs their secondary keys. Plus a means to have a CA signing user keys bound to JIDs
Steve Killehas joined
Guushas left
Guushas joined
labdsfhas left
Guushas left
Guushas joined
flow
Let me focus on the CA thingy first: What is the advantage over a CA verifying the "identity" by signing user keys compared to the public key in PEP? If you consider Let's Encrypt, then LE just checks that you have control over a certain "namespace", which is pretty much what public key in PEP provides.
flow
What additional benefit do you envison could a CA provide?
404.cityhas left
Guushas left
Guushas joined
Guushas left
Guushas joined
kasper.dementhas joined
matlaghas left
Ge0rG
flow: good point. A public CA doesn't help in needing to trust the server, and no amount of OOB will help
andyhas joined
andyhas left
andyhas joined
Ge0rG
A corporate CA might help, but then it's probably operated by the same people the server is
mrdoctorwhohas left
mrdoctorwhohas left
danielhas left
danielhas joined
Martinhas left
404.cityhas joined
Martinhas left
Martinhas left
Martinhas left
Martinhas left
Martinhas joined
Martinhas left
Dave Cridlandhas left
Dave Cridlandhas joined
mrdoctorwhohas joined
la|r|mahas joined
la|r|mahas joined
kasper.dementhas joined
Ge0rG
The major problem I see with OMEMO is multi-device key management. A client message of "You seem to have added a new device at 12:10, with the following fingerprint: ... - correct? [Yes] [No]" with a cross-key signing is vastly better than forcing every one of your contacts to manually verify that fact.
j.rhas joined
jubalhhas joined
j.rhas left
muppethhas joined
muppethhas joined
danielhas left
danielhas joined
lskdjfhas left
Syndace
Ge0rG: I like the idea a lot! Has this been discussed before?
Ge0rG
Syndace: I suggested that to daniel back when OMEMO was being designed.
Ge0rG
The idea was not approved.
Syndace
Hmm, is there a mailing list thread or do you remember the reason?
Ge0rG
Apparently because automatically trusting a new key which is signed by your friend's old key is a security issue.
Ge0rG
Or maybe because signing keys is not trivial. Or both.
daniel
Why not share the key?
daniel
That seems easier than cross signing
Ge0rG
daniel: what exactly do you mean by "share the key"
daniel
Using the same key
daniel
Like OX
Ge0rG
daniel: ah, a user key as opposed to a device key
Syndace
How do you get the key to the new device
Ge0rG
Syndace: QR code with a red border:P
daniel
Yeah. Or put it in the cloud
Syndace
True, but then again, if one device gets compromised, all of them are
Ge0rG
Syndace: yes
Ge0rG
Syndace: but that doesn't matter in practice.
daniel
And that's the same as cross signing
Ge0rG
Syndace: if one if your devices is compromised, the attacker gets the local history of that device and everything sent to you
Syndace
The cross signing issues don't matter as well
Ge0rG
daniel: as stated above, I prefer user keys to device keys.
Ge0rG
daniel: I thought that OMEMO required device keys anyway, so a two-tier key arch was my second best suggestion
jonasw
daniel, no, it’s not the same as cross-signing. a malicious key added by cross-signing can be removed individually and the damage is contained. if all your devices share the same key, you have to roll your key over entirely to fix the damage. right?
Ge0rG
or cross-signing
daniel
How do you revoke a key though
Ge0rG
start with a new user key.
daniel
I mean in case of device keys
daniel
What I'm saying is that I don't see the benefits of cross signing of sharing the private key
Ge0rG
daniel: you *could* add revocations to cross-signatures.
jonasw
hm
Ge0rG
the point that I made in the beginning (and am still making) is: with the user managing their own keys, you have O(1) key management overhead. With the contacts managing the user's keys you have O(N) for N contacts, and you have zero decision agency
Ge0rG
did Daniel just buy a new Pixel phone, or is the NSA impersonating? How am I supposed to know?
daniel
It's not news that trust is hard
Ge0rG
daniel: and you are making it even harder.
rishiraj22has left
daniel
Than?
daniel
Otr?
Ge0rG
daniel: harder than needed
daniel
Otr allowed for funny questions that I didn't knew the answer to
daniel
That was pretty fun
Ge0rG
daniel: are you still on holiday? Have a nice time and let's talk seriously when you're back
j.rhas joined
lumihas joined
la|r|mahas joined
kasper.dementhas joined
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
kasper.dementhas left
kasper.dementhas joined
Guushas left
Dave Cridlandhas left
Guushas joined
Guushas left
Dave Cridlandhas left
Guushas joined
kasper.dementhas left
danielhas left
danielhas joined
andyhas left
jubalhhas joined
danielhas left
danielhas joined
intosihas joined
doublehas left
doublehas joined
flow
Ge0rG, I still don't know how "xmpp and OMEMO identity models extend[ing] each other" fits into the picture, and what you suggest should change
danielhas left
danielhas joined
remkohas joined
kasper.dementhas joined
Ge0rG
flow: apparently it wasn't clear to everybody. My statement was utterly sarcastic.
flow
Ge0rG, so besides cross-signing keys, you are happy with omemo?
Ge0rG
flow: I'm happy with ignoring its existence.
Dave Cridlandhas left
flow
It appears you are not very good at it
Dave Cridlandhas left
404.cityhas left
Dave Cridlandhas left
Ge0rG
flow: for practical matters, I am.
Dave Cridlandhas left
Dave Cridlandhas left
kasper.dementhas joined
danielhas left
danielhas joined
Dave Cridlandhas left
Valerianhas joined
Dave Cridlandhas left
jubalhhas joined
Dave Cridlandhas left
danielhas left
Ge0rG
obviously, I can't completely ignore it with my Council member hat on.
danielhas joined
kasper.dementhas joined
kasper.dementhas left
kasper.dementhas joined
nycohas left
nycohas joined
Syndace
alright honestly, why is the hate against omemo so huge in this whole community? I haven't had problems with it, not one single time.
kasper.dementhas joined
Syndace
because checking fingerprints is a pain? because "This message is OMEMO encrypted, your client does not seem to support it"?
daniel
A little bit of both probably. And people also like to complain about things
winfriedhas joined
Syndace
that's far from enough reason to spread such hate
daniel
That's the internet
Kev
I don't think anyone /hates/ it, it's a protocol. I think several people see there are issues with it.
Ge0rG
And other people think that E2EE should be enforced upon everyone, which leads to hate indeed.
MattJ
that isn't specific to OMEMO
Ge0rG
E2EE by means of OMEMO.
Ge0rG
And then non-technical users complain that their messages don't get delivered, and we have one *additional* place to look for.
MattJ
Someone spent months trying to contact me once, but they had mod_require_otr enabled on their server and I couldn't reply
MattJ
and the only contact I had for them was their JID
MattJ
I had a similar situation where I logged into my account with Conversations to test something, and then a bunch of people couldn't message me anymore
Ge0rG
MattJ: should've sent them "?OTRv2 hi please disable mod_require_otr"
jonasw
Ge0rG, more than one place, because OMEMO is such a mess of moving parts
Ge0rG
MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients.
MattJ
I don't consider myself an "OMEMO hater" though, I think I've rarely mentioned it... I've many other things to complain about before I could get to that :)
MattJ
jonasw, is it such a mess?
Syndace
> MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients.
What?
jonasw
MattJ, with the unstable PEP implementations out there and inconsistency in handling of OMEMO messages with and without surrogate body (on all levels), yes
MattJ
Both seem like things that could be relatively easily fixed
MattJ
A non-PEP key distribution protocol would be pretty trivial
andyhas joined
Ge0rG
MattJ:
> Both seem like things that could be relatively easily fixed
The story of XMPP.
MattJ
Ge0rG, some things are more easily fixed than others :)
MattJ
OMEMO does not seem like our worst problem by far
kasper.dementhas joined
MattJ
Syndace, some of my clients don't support OMEMO, I don't particularly want to use OMEMO either
Syndace
What about: When starting a new chat, the client sends the messages unencrypted in the message body AND encrypted using OMEMO at the same time and based on whether the response is OMEMO encrypted the client decides whether to stick with omemo or go on plaintext
MattJ
Syndace, I think my problem is more with the way Conversations enforces it, than the protocol
Ge0rG
Syndace: doesn't work in multi-client scenarios
Syndace
What does mutli client scenario mean? group chat?
MattJ
Syndace, multiple clients on the same account
MattJ
which just about every XMPP developer has
Syndace
True, all of them need OMEMO to receive the message
Ge0rG
all of them need to support OMEMO and have their prekey published and trusted by the sender
Ge0rG
that's a large number of moving parts.
Syndace
yeah i see
Ge0rG
especially if you test multiple desktop clients, multiple mobile clients and do web sessions from time to time
vanitasvitaehas left
Ge0rG
so you either end up with one client polluting your PEP with keys, leading to all your contacts sending you garbage, or with other corner cases of the protocol
Kev
As long as clients don't go enabling omemo for you automatically, which would obviously be broken, I don't see this as particular problem.
Kev
Or, rather, not something that can be solved.
Kev
Because once you hit the "I want to e2e" switch, you *want* to avoid non-e2e clients getting plaintext.
Ge0rG
Kev: I've heard that Conversations will auto-enable E2EE.
Kev
And so you're just not going to flick that switch if you want to use non-e2e clients. Irrespective of whether that's omemo or other.
jonasw
Ge0rG, Conversations *does* auto-enable E2EE
jonasw
even if no keys are seen.
jonasw
(you get a warninng and an option to disable when you send a message then)
Ge0rG
Besides of this, there is no secure way to communicate the status of that hypothetical "I want to e2ee" switch.
rishiraj22has left
jonasw
't
Ge0rGnow attempts to rhyme "e2ee" to "break free"
Kev
Ge0rG: Well, there's HSTS-ish at least.
Kev
Ge0rG: You want to rhyme it to "to break free"
Kev
Then it works.
Ge0rG
Kev: except that HSTS relies on a semi-corrupt CA hierarchy
MattJ
Syndace, and here you get the problem described by XMPP developers. When we (e.g. I'm a server developer) have to deal with users who encounter these problems and want to know why their messages are not being delivered... it's extremely difficult to help them
Kev
Do I not mean HSTS? I mean "Ok, I'm telling you now, don't use me in the future if I stop encrypting", anyway.
Ge0rG
I don't want to be used by Kev
Ge0rG
irregardless of E2EE
MattJ
Syndace, I think that could be solved with better tooling (as well as improving client UIs)
jonasw
Ge0rG, lol
Kev
That's what you think, but you're mistaken (Ge0rG)
jonasw
get a room
tahas joined
Ge0rG
jonasw: if only MUC invitations were working reliably.
Syndace
I think it's a very bad idea that clients enable encryption even if they know that one of the receiving devices does not support it. Silently dropping messages is a super bad idea confusing WhatsApp-level users
Ge0rG
Syndace: there is no notion of "user's devices" so it's impossible to know whether all devices support OMEMO
jonasw
Syndace, problem is: if you don’t do that, servers (which are the bad guys™ in the e2ee scenario) can trivially downgrade you to plaintext
Kev
jonasw: They have to do it from the get-go, though.
jonasw
Kev, in your case, yes
Kev
Well, depending on exactly what's implemented :)
Kev
Right.
404.cityhas joined
404.cityhas left
doublehas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Dave Cridlandhas left
Dave Cridlandhas left
kasper.dementhas joined
kasper.dementhas joined
mrdoctorwhohas left
intosihas joined
danielhas left
danielhas joined
kasper.dementhas left
kasper.dementhas joined
vanitasvitaehas left
kasper.dementhas left
Guushas left
Guushas joined
blablahas joined
Guushas left
Guushas joined
blablahas joined
kasper.dementhas joined
karphas left
karphas joined
blablahas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
winfriedhas joined
Dave Cridlandhas left
kasper.dementhas joined
Zashhas joined
winfriedhas joined
jerehas joined
kasper.dementhas joined
rishiraj22has left
Steve Killehas left
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
blablahas joined
rishiraj22has left
Holgerhas left
mimi89999has left
kasper.dementhas joined
mrdoctorwhohas joined
tahas left
andyhas left
kasper.dementhas joined
winfriedhas left
Guushas left
Guushas joined
winfriedhas joined
Str4tocasterhas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
ralphmhas joined
intosihas left
doshas joined
matlaghas left
marchas joined
doshas left
doshas joined
Str4tocasterhas left
kasper.dementhas joined
flowhas left
Kevhas left
kasper.dementhas joined
Str4tocasterhas joined
Str4tocasterhas left
Steve Killehas left
vanitasvitaehas left
Guushas left
Guushas joined
Chobbeshas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
Guus
Made it just in time 🙂
MattJ
The question is, who else did? :)
Guus
You, for one. 🙂
MattJ
nyco, around?
MattJ
ralphm seems to have been popping in and out, I think he's on mobile
Guus
nyco mailed that he was not going to be here today.
kasper.dementhas joined
Guus
Martin?
MattJ
Oh, missed that
MattJ
Oh, Gmail marked that thread as "Not important" and I overlooked it
Guus
that'll teach you to have such a filter activated on my name. 🙂
rishiraj22has left
Guus
Shall we try this again next week?
MattJ
Yeah, I think so
MattJ
btw, Martin != Martin Hewitt
intosihas left
intosihas joined
Guus
ah. didn't know, tx
Guus
ok, I'm off for a bit then. ttyl!
MattJ
See you :)
kasper.dementhas joined
Guushas left
doshas left
doshas joined
vanitasvitaehas left
Dave Cridlandhas left
kasper.dementhas left
vanitasvitaehas left
Alexhas joined
vanitasvitaehas left
vanitasvitaehas left
doshas left
matlaghas joined
matlaghas joined
tuxhas joined
kasper.dementhas joined
jjrhhas left
jjrhhas left
danielhas left
danielhas joined
jjrhhas left
kasper.dementhas left
kasper.dementhas joined
doshas joined
lskdjfhas joined
mrdoctorwhohas joined
Guushas left
Guushas left
vanitasvitaehas left
Guushas left
vanitasvitaehas left
vanitasvitaehas left
rishiraj22has left
rishiraj22has left
vanitasvitaehas left
Ge0rGhas left
rishiraj22has left
Ge0rGhas left
Guushas left
vanitasvitaehas left
blablahas left
blablahas joined
tuxhas joined
ralphmhas joined
Valerianhas left
tuxhas joined
rishiraj22has left
la|r|mahas left
Kevhas left
Guushas left
Guushas left
Martinhas left
Chobbeshas joined
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas joined
blablahas joined
tuxhas joined
Guushas left
jubalhhas joined
Guushas left
vanitasvitaehas left
Guushas left
Guushas left
Guushas left
peterhas joined
Nekithas left
Guushas left
Guushas left
Nekithas joined
vanitasvitaehas left
Yagizahas joined
jubalhhas left
Chobbeshas joined
Syndace
So, I collected the OMEMO issues that I was able to filter from the short discussion earlier and wrote down my thoughts and ideas about them: https://hackmd.io/x70DAtLgSHqBzke49_vBrg
I'd like to hear whether I grasped the core of the issues and whether my thoughts/ideas make any sense lol.
Also please tell me what's missing and feel free to add your own ideas and comments.
Dave Cridland
Syndace, Are you aware of the MLS work under way in the IETF?
jubalhhas left
Syndace
Oh boy, I was not
MattJ
Dave Cridland, I'm assuming you are following it because you keep talking about it. How far is it from something everyone can implement?
Guushas left
mrdoctorwhohas joined
Valerianhas joined
Guushas left
goffi
Syndace: we can't send some data becose there is not full stanza encryption. I'm specially missing xml:lang like I've explained on the @standard list (and some other like message markup).
jonasw
Syndace, section 1, Idea #2 seems waaaay too complex
Guushas left
Syndace
jonasw, well but I think it would fix all issues at once
Dave Cridland
MattJ, Early days. But it's got some serious people working on it. You can actually get libraries and work with the current design, but it's approximately as scary as using TLS 1.3 draft 3 - chances of everything interopping in the future are pretty low.
jonasw
at the cost of UX, Syndace
Guushas left
Dave Cridland
MattJ, I'm not saying we should switch now. I'm just saying we should be prepared to write off OMEMO as an experiment in a year or so.
Syndace
jonasw: True
Syndace
Dave Cridland: Well great.
jonasw
solving bad UX by making it worse doesn’t seem good to me :)
Syndace
jonasw: Not worse I think
MattJ
Dave Cridland, I don't think that's a reason to not attempt to fix problems we have today in parallel
Guushas left
MattJ
If MLS is ready in a year, it's another 2-3 years before clients implement it widely enough
Syndace
jonasw: Do you think it's a super UX killer if you have to select which devices you want to exchange encrypted data with?
MattJ
meanwhile OMEMO is already quite popular today, even Pidgin supports it
Dave Cridland
MattJ, Well, I think we have an opportunity to show XMPP can be leading edge in this kind of thing.
MattJ
Sure, I'm up for that
MattJ
But the carousel of E2EE solutions is also a bit of a joke by now
jonasw
Syndace, yes, other systems have E2EE without such annoyinaces
Dave Cridland
MattJ, Yes, indeed.
jonasw
MattJ, no, pidgin *does not* support it.
MattJ
Let's not leave what we have working today at 90% for the next 1-3 years
jonasw
pidgin has two plugins both of which have their own quirks
jonasw
and it doesn’t even "have" those plugins as in they’re distributed, no, you have to get them from somewhere.
MattJ
jonasw, that worked against my argument, so I glossed over that (but yeah)
jonasw
Dave Cridland, MattJ, if we’re going to do another round in the E2EE protocol carousel (good term by the way), I’d suggest to tackle (nearly) full stanza encryption, to at least give it a benefit over staying with status quo
Syndace
jonasw: Is there a comparable system which allows multi-device e2ee where some devices do e2ee and some don't?
tahas joined
jonasw
Syndace, I don’t know, actually. but users won’t care about that
jonasw
in the end, you can have signal/whatsapp/whatever on botth your laptop and your phone and it works just fine -- even if on your laptop, you just view stuff which is on your phone via webrtc or something
jonasw
and competing against that with a complex selection dialog whenever you want to do e2ee, just nope
kasper.dementhas joined
Guushas left
jubalhhas joined
Syndace
jonasw: We could reduce it to "start private chat" which just starts the chat with all OMEMO-enabled devices and doesn't ask which devices should be included
Syndace
That way it would be a button click
jonasw
Syndace, and then we’re exactly where we are right now
MattJ
but not by default
Dave Cridland
jonasw, Sure. But given MLS also handles group chat (in fact, it *doesn't* handle anything but), that shoudl also provide impetus.
jonasw
Dave Cridland, OMEMO handles group chat today
Syndace
jonasw: Not really, because it's two seperate chats: One plaintext and one encrypted and the important thing: The user is aware that not all devices will get all messages
goffi
jonasw: is there a spec for that?
Dave Cridland
jonasw, Sort of. It handles groupchats by keying M times. MLS does it in one.
jonasw
goffi, dunno
jonasw
Dave Cridland, sorry, I have no idea
jonasw
I just know that it is possible
Guushas left
Dave Cridland
goffi, Good grief no. Did you think OMEMO was one of those *open* standards?
goffi
I know Conversation and Gajim handle it, but I think it's unofficial for now (i.e. no XEP)
jonasw
Syndace, "but other systems do have e2ee by default, why can’t you?"
lovetoxhas joined
Guushas left
Syndace
jonasw: Because we don't forve you to use it. You can though, by clicking this button right here
Zash
e2ee as an afterthought is going to be infinite pain whatever way you do it
MattJ
goffi, I'm not sure a spec is really needed
jonasw
Syndace, that doesn’t need any additional magic though. just *some* clients stepping back from the "OMEMO by default and everywhere" paradigm
MattJ
goffi, it's just MUC, you fetch the keys of all participants
Guushas left
Syndace
goffi, I think they just parse the MUC-style JID into the normal JID and then use OMEMO as usual
Guushas left
jonasw
Zash, WhatsApp supposedly managed to do it as an afterthought
goffi
Gajim told me last time I was in a MUC for testing, that it was working with member only rooms something like that (don't remember the message)
Syndace
jonasw: WhatsApp has one binary and forces usage of e2ee, would be easy with these preconditions
goffi
this should be explained in a XEP, even if it's short
Syndace
(or three binaries for each OS, whatever)
Guushas left
Zash
jonasw: supposedly. also they're one company who do all the clients
waqashas joined
Guushas left
Dave Cridland
I suspect we'll need an HSTS equivalent for E2EE, certainly, and then move plaintext->opportunistic->e2ee-always
Zash
if clients were registered and known by the server then maybe
goffi
we are still blocking a bunch of XEP with OMEMO by default
Guushas left
goffi
as long as there is no full stanza encryption
Guushas left
Dave Cridland
Zash, I suspect client registration has ot become a Thing, anyway. There's a whole lot of optimizations we could do if we had that.
Guushas left
goffi
no more last message correction, no more in band real time text, no more, no more language detection, no more markup.
Zash
goffi: but we have the markdown-ish thing now /s
jonasw
goffi, but markup is in the <body/> nowadays anyways!!
Guushas left
Dave Cridland
goffi, Honestly, you needn't argue for full-stanza. ESessions had that a decade ago, I have no idea why OMEMO doesn't.
Zash
jonasw^5
goffi
Zash: don't tell me :'(
jonasw
Dave Cridland, possibly because time-to-market mattered more than doing things right?
jonasw
Zash, ^5
Dave Cridland
jonasw, Probably.
jonasw
Dave Cridland, I’d love if we could maybe not repeat the same mistake with whatever MLS integration will happen.
Dave Cridland
jonasw, Yes. I'd like to do that one right.
vanitasvitaehas left
Syndace
Any info on how/whether MLS handles mixed plaintext-only clients and encrypting clients?
jonasw
Dave Cridland, Zash, if it ever gets less hot so I can think straight for more than 5 minutes in a row, I’m going to try to make some device identification thing in prosody. I need per-device passwords anyways.
Dave Cridlandhas left
Syndace
If we had device identification we could issue a simple warning: "If you send this message encrypted, only jid: phone and jid: laptop can receive the message. jid: web and jid: work can not."
goffi
I would argue that I rather use OX by default, I'm less interested in PFS that in mentioned features.
Zash
jonasw: I hear MattJ was working on that
goffi
and OX do full stanza encryption.
MattJ
jonasw, er, yeah, I have a mod_device_tracker
MattJ
I can publish it later today or tomorrow
jonasw
MattJ, I’m thinking about doing things in SASL
pep.
MattJ: tracker!! I knew it
MattJ
pep., it's ok, it asks for consent
Zash
jonasw: FWIW you could have per-device usernames too (or username+device), since they need have no relation to the bound JID
jonasw
Zash, I was more thinking of using the second identity one can pass in sasl
jonasw
if it’s a full JID with the bare JID equal to the one you’re authing for, the resource is the device ID
Zash
jonasw: modulo client support
jonasw
Zash, yeah...
jonasw
but do clients support getting forced to a different bare JID?
Zash
Sure
jonasw
I need to have tests for that.
jonasw
I’m not sure what aioxmpp would do
Zash
+1
Zash
Moar tests :)
jonasw
Zash, fun fact, I’ll probably go for device@username for per-device-passwords in IMAP :)
Dave Cridland
jonasw, See https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00
Zash
jonasw: Have you noticed the client-uses-full-bind-something pidgin sends in the stream start?
jonasw
Zash, no
Zash
jonasw: Which had something to do with GTalk
jonasw
Dave Cridland, in my scenario, the devices would never learn the actual account password
jonasw
which is something I’d like to have
jonasw
actually, this is uspposed to be client certificates lite
jonasw
because client certs are hard
vanitasvitaehas left
Zash
It could assign you a different hostname even, if you had whatever the hosted domain thing was
jonasw
Zash, crazy stuff
jonasw
need to keep that in mind; that might be useful to have to support legacy clients
Zash
sure
Zash
There are some modules in Prosody where the SASL username ends up differently from the JID localpart
jonasw
interesting
Zash
Some PHP forum one for example
Zash
One where you can have characters in the username that don't pass nodeprep
Dave Cridland
jonasw, Do a PIN-check on another session? But anyway, I'm happy to knock around idea on that with you.
jonasw
Dave Cridland, sounds good, but as I said .... it’s too hot here to think
tahas joined
jonasw
Dave Cridland, my idea was somewhat like this:
- to add a new device, you generate an auth-code on your first device and enter that in the new device. it performs either something SASL2 or a variant of IBR to set a password for itself (the password is never shown to the user)
- it will always authenticate with that password (somewhat like your CLIENT-KEY I suppose)
- server can now track the device, which also means that a user can revoke any device at any time (e.g. lost or stolen)
Valerianhas left
jonasw
Dave Cridland, IIRC, client key had the issue that when the counter goes out-of-sync, you need to re-authenticate using the normal SASL mechanisms?
alacerhas left
alacerhas joined
Dave Cridland
jonasw, Yes. It's designed as a "Remember this device" to go along with TOTP, and not exactly wehat you're after.
jonasw
mmmhm
Martinhas left
Dave Cridland
jonasw, But that counter is intentional - anyone stealing the credential from the client cannot use it from another device if the original device is still in use - the counter gets out of sync and the server-side token is killed.
jonasw
I think CLIENT KEY is orthogonal to this, yeah. It could be used in a, as you say, "Remember this device" fashion to temporarily replace the SCRAM-with-device-password+TOTP flow if TOTP is used,.
Chobbeshas joined
jonasw
Dave Cridland, yupp, that’s good
Dave Cridland
jonasw, Oh, and it's designed such that you can't DoS the token by guesswork or stealing it from the server.
muppethhas joined
muppethhas joined
jonasw
it looked pretty solid when I looked at it back then, yeah
jonasw
but IANAC
404.cityhas joined
Dave Cridland
C = Cryptographer?
jonasw
yes
Dave Cridland
Nor am I, but I play one on TV.
jonasw
:D
Valerianhas joined
Chobbeshas joined
danielhas left
pep.has joined
alacerhas left
vanitasvitaehas left
muppethhas joined
Guushas left
Guushas left
pep.
Syndace: in your pad, section 4 before idea1, you are confusing omemo and e2ee. e2ee doesn't require PFS
vanitasvitaehas left
jubalhhas joined
Martinhas left
vanitasvitaehas left
vanitasvitaehas left
Martinhas left
Syndace
pep.: Right.
danielhas joined
Guushas left
Guushas left
jonasw
people suggesting:
> In general, a short “yo, please deactivate OMEMO” plaintext answer should be enough. But this can be annoying if it happens too often!
clearly have no idea at which level of technological literacy some people operate
pep.
Indeed
jonasw
Syndace, append to your list please "I re-installed Conversations and now I can’t access my history anymore", because people aren’t expecting PFS.
Syndace
jonasw: lol, yes I know that some people don't know what OMEMO is and how to disable it, come on don't take this so literal :D
pep.
Syndace: this is a real world issue :x
nycohas left
labdsfhas joined
Syndace
jonasw: Better example of what to write?
Guushas left
Andrew Nenakhov
Our take on encrypted conversations that we plan to implement soon is to have separate encrypted and decrypted chats. Like telegram's secret chats.
Guushas left
vanitasvitae
Syndace: after having implemented OX (OpenPGP for XMPP) I think one huge improvement that OX is having over OMEMO is the ability to encrypt arbitrary extension elements. I think full stanza encryption is rather unrealistic for xmpp, but you can put all the sensitive data into an encrypted container and be done :)
vanitasvitae
We should really port this to OMEMO / put it in a standalone XEP and let OX and OMEMO depend on it
Andrew Nenakhov
Telegram also solves multidevice e2ee quite simply: secret chats are one on one device only.
Syndace
Andrew Nenakhov: Interesting, who is "our"?
Andrew Nenakhov
Xabber.
vanitasvitae
Andrew Nenakhov: the single device part is one of the things that keep me from using secret chats :/
Guushas left
Guushas left
Andrew Nenakhov
I also hate pfs obsession
Valerianhas left
lovetox
nobody has a pfs obsession
lovetox
its just what we have
Andrew Nenakhov
Publish a pgp key, share it to all devices, have your history everywhere.
vanitasvitae
Moxie does :D
lovetox
we cant just snip our fingers and invent super secure encryption protocols
lovetox
Andrew Nenakhov, yes you can do that with OX
Andrew Nenakhov
If you care that much about privacy, don't lose that key.
lovetox
Omemo was just there first, and its easier to implement
Andrew Nenakhov
> Moxie does :D
A lot of other guys do too. Constantly bombard our issue trackers with demands.
vanitasvitae
:D I have heard of that infamous bug report ;)
Syndace
What about a mechanism to synchronize local history from another device? xD
Andrew Nenakhov
:-D
Andrew Nenakhov
That bug report is, yes, epic
blablahas joined
MattJ
Syndace, that has been discussed in the past - the protocol is already there - XEP-0313 could work between clients just as it does between client and server
Zashhas left
Andrew Nenakhov
Btw, why would people want "full stanza encryption"?
Zashhas joined
Andrew Nenakhov
If you encrypt whom you address stanza, it'll never be delivered 😂
rishiraj22has left
vanitasvitae
At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D
lovetox
obviously not the top element..
MattJ
vanitasvitae, that has also been discussed and done before
Steve Killehas left
Steve Killehas left
labdsf
MattJ: gajim recently removed this feature
Syndace
MattJ: Wondering how serious to take this idea
Andrew Nenakhov
What is there to encrypt besides top element 😂😂😂
lovetox
every child element?
Syndace
Would be pretty cool to have history even on fresh OMEMO devices
MattJ
Andrew Nenakhov, OOB element for file transfers, for example
labdsfhas left
labdsfhas joined
Andrew Nenakhov
> Would be pretty cool to have history even on fresh OMEMO devices
As I understand OMEMO, this wish goes against all it stands for. :-/
Syndace
Not if you can sync the local history from your other devices or your chat partners
labdsf
Andrew Nenakhov: Signal has synchronization between start vices
labdsf
Between devices*
lovetox
it can provide this, because it does not have to deal with different clients
Syndace
lovetox: Doesn't sound very hard to throw the serialized XML into OMEMO instead of a plaintext message for nearly-full-stanza-encryption
lovetox
this would mean making a protocol for exchanging databases
Steve Killehas joined
lovetox
who said full stanza encryption is hard? as some people point out this exists probably for a decade in xmpp
Syndace
What about substanzas that are meant for the server (like hints)?
lovetox
you obviously cant encrypt them because then they are useless
Syndace
I was wondering whether to treat them in a special way or to just ignore them
lovetox
with full stanza encryption we dont mean full like everything
lovetox
we mean all data that are not necessary for the server to function
Guushas left
nycohas left
Andrew Nenakhov
> Andrew Nenakhov: Signal has synchronization between start vices
Doing that is definitely possible in a number of ways, every single of them denying all advantages their protocol has over PGP.
Andrew Nenakhov
You can sync history directly between devices. You can share keys and download and decipher messages from server archive
Andrew Nenakhov
But why bother using omemo if you plan to do that?
404.cityhas left
Syndace
signal uses omemo aswell (basically)
Syndace
why do you think they do it that way? because its convenient probably
vanitasvitae
If you do the backup exchange using OMEMO, you dont lose any advantages of OMEMO
jjrhhas left
vanitasvitae
if you do it via OpenPGP however, your whole history is on the server twice, once OMEMO encrypted and once via OpenPGP. In that case you lost pfs due to the OpenPGP copy which can in theory be decrypted in the future.
jjrhhas left
vanitasvitae
So for backup exchange you'd want to generate a single-use key.
Andrew Nenakhov
Why twice? One openpgp is enough.
Andrew Nenakhov
Backup exchange is also bad ux by the way.
Andrew Nenakhov
You want your messages everywhere at once.
Andrew Nenakhov
So in the end if you want security and convenience , just run your own server.
vanitasvitae
Then you need OpenPGP and you cannot have pfs
Andrew Nenakhov
Because in xmpp the only ones who are affected by e2ee are server operators.
jjrhhas left
goffi
ho Gajim removed direct stream encryption? What a pity, I find it the most secure way if you have something really sensitive to say
goffi
I guess same effect can be achieved with XEP-0396 nowaday
Guushas left
lovetox
Gajim never head direct stream encryption
Guushas left
lovetox
and why is it a pity if no client supported that?
Dave Cridlandhas left
Guushas left
doshas left
labdsfhas left
moparisthebesthas joined
moparisthebesthas joined
Link Mauve
Hi, what should happen with MAM when a client did a <query/> without specifying a @queryid? Should the <result/>s also not contain one?
Link Mauve
So far I made it required in my parser but I guess it should be optional due to that.
lovetox
yes Link Mauve correct
lovetox
dont add a query element if the client doesnt set one
lovetox
makes no sense, because its a identifier for the client
lovetox
if it set none it doesnt need it
Link Mauve
Yup.
Guushas left
Guushas left
karphas left
karphas joined
Alexhas left
Guushas left
kasper.dementhas joined
Link Mauve
Wut, the changelog of RSM says that the <index/> element has been removed, but it is still present thrice in the text (including twice in examples).
jonasw
maybe a different <index/> element? *hope*
flow
Link Mauve, attribute vs element?
Link Mauve
Nope, I checked already.
Link Mauve
flow, nope.
flow
ahh right, the elemnt still appears in the text
Link Mauve
Hmm, I think I should split my RSM element into query and result, that would make it a lot easier to understand what’s going on.
flow
Who is 'vm'?
Link Mauve
Someone from before my time, I guess.
rionhas left
kasper.dementhas joined
michaelhas joined
jonasw
This one just came up in another room: https://xmpp.org/extensions/xep-0238.html
jonasw
do we maybe want to deprecate/obsolete/reject that?
jonasw
it seems to be ... way out of date
jonasw
and there doesn’t seem to be any interest in refining it
karphas left
karphas joined
michaelhas left
Chobbeshas joined
lskdjfhas joined
karphas left
karphas joined
alacerhas joined
Link Mauve
jonasw, +1, although in the past we’ve considered deferred as a tombstone.
Link Mauve
But I’m still +1 to explicitly obsolete it.
kasper.dementhas joined
jonasw
yeah, deferred isn’t explicit enough
Link Mauve
And I think we shouldn’t let XEPs stay in limbo like that forever.
Yagiza
If I implement deffered XEP in my software, may it change its status?
Link Mauve
Yagiza, you should send an email to standards@ to explain why imo, then someone will most likely revisit it.
Zash
Yagiza: Possibly, especially if you write to the standards@ list or the author with feedback
jonasw
Yagiza, there are two types of deferred XEPs (and you cannot tell them apart by the status): those which are abandoned, and those which are "good enough" and which are silently implemented everywhere
jonasw
Yagiza, so if you implement a deferred XEP, post any feedback you have to standards@ (even if it’s just "implemented it, it solves my issue X"), that might trigger advancement to Draft
Link Mauve
You may also send a change, anything, something you found missing/misformulated/anything in the text, which would automatically put it back to Experimental.
Zash
jonasw: I'd say there's some gray area inbetween, where the author just happens to be busy with other stuff
jonasw
Zash, I’d call that "abandoned", even though that’s harsh
Link Mauve
Zash, can confirm. :-°
404.cityhas joined
Zash
jonasw: sounds intentional then, which it might not be
jonasw
hm, ok
Yagiza
I just want to try implementing XEP-0371 in my client as a good solution for file transfer.
jonasw
Yagiza, uh... in combination with XEP-0234?
Alexhas left
Yagiza
Yes, of course
Yagiza
Also, its implementation may increase chances of successful Jingle RTP session.
Link Mauve
This one is an instance of the good kind of deferred XEP.
lorddavidiiihas joined
mikaelahas joined
Guushas left
muppethhas left
muppethhas joined
Yagiza
Link Mauve, so, if I implement it, it may make things better?
jonasw
yes
Yagiza
Ok. Sounds good.
karphas left
karphas joined
Zash
Higher chance of things becoming better if you send feedback to standards :)
waqashas left
karphas left
karphas joined
karphas left
karphas joined
Alexhas joined
doshas joined
Link Mauve
In pubsub#event, I see @node being defined on item, but I don’t see it used anywhere in the XEP.
Link Mauve
What and where could it be used for?
Alexhas joined
Zash
Section?
Link Mauve
XML Schema.
Zash
https://xmpp.org/extensions/xep-0060.html#example-2 that @node ?