-
jonasw
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
-
Ge0rG
Isn't it awesome how the xmpp and OMEMO identity models extend each other?
-
jonasw
I sense sarcasm
-
Guus
Ge0rG, sarcasme? Nahhh...
- Guus raises fist to autocorrect.
-
flow
Ge0rG, while it's trivial to change that?
-
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
-
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?
-
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?
-
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?
-
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...
-
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?
-
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
-
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?
-
Ge0rG
flow: good point. A public CA doesn't help in needing to trust the server, and no amount of OOB will help
-
Ge0rG
A corporate CA might help, but then it's probably operated by the same people the server is
-
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.
-
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.
-
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
-
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
-
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.
-
flow
It appears you are not very good at it
-
Ge0rG
flow: for practical matters, I am.
-
Ge0rG
obviously, I can't completely ignore it with my Council member hat on.
-
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.
-
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
-
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
-
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
-
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
-
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.
-
jonasw
't
- Ge0rG now 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
-
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.
-
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.
-
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. 🙂
-
Guus
Shall we try this again next week?
-
MattJ
Yeah, I think so
-
MattJ
btw, Martin != Martin Hewitt
-
Guus
ah. didn't know, tx
-
Guus
ok, I'm off for a bit then. ttyl!
-
MattJ
See you :)
-
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?
-
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?
-
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
-
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
-
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
-
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?
-
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
-
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
-
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?"
-
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
-
Syndace
goffi, I think they just parse the MUC-style JID into the normal JID and then use OMEMO as usual
-
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)
-
Zash
jonasw: supposedly. also they're one company who do all the clients
-
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
-
goffi
as long as there is no full stanza encryption
-
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.
-
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!!
-
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.
-
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.
-
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
-
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
-
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)
-
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?
-
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
-
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,.
-
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.
-
jonasw
it looked pretty solid when I looked at it back then, yeah
-
jonasw
but IANAC
-
Dave Cridland
C = Cryptographer?
-
jonasw
yes
-
Dave Cridland
Nor am I, but I play one on TV.
-
jonasw
:D
-
pep.
Syndace: in your pad, section 4 before idea1, you are confusing omemo and e2ee. e2ee doesn't require PFS
-
Syndace
pep.: Right.
-
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
-
Syndace
jonasw: Better example of what to write?
-
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.
-
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 :/
-
Andrew Nenakhov
I also hate pfs obsession
-
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
-
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
-
Andrew Nenakhov
Btw, why would people want "full stanza encryption"?
-
Andrew Nenakhov
If you encrypt whom you address stanza, it'll never be delivered 😂
-
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
-
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
-
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
-
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
-
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?
-
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
-
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.
-
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.
-
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
-
lovetox
Gajim never head direct stream encryption
-
lovetox
and why is it a pity if no client supported that?
-
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.
-
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.
-
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
-
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.
-
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. :-°
-
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?
-
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.
-
Yagiza
Link Mauve, so, if I implement it, it may make things better?
-
jonasw
yes
-
Yagiza
Ok. Sounds good.
-
Zash
Higher chance of things becoming better if you send feedback to standards :)
-
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?
-
Zash
Section?
-
Link Mauve
XML Schema.
-
Zash
https://xmpp.org/extensions/xep-0060.html#example-2 that @node ?
-
Link Mauve
This is on items, not on item.
-
Zash
Wait where do you see a node attr?
-
Link Mauve
Line 7007 of the XML file in the xeps repository.
-
Zash
Which object? :)
-
Link Mauve
What do you mean?
-
jonasw
https://github.com/xsf/xeps/blob/master/xep-0060.xml#L7001
-
jonasw
Link Mauve, might’ve been a mistake
-
jonasw
node doesn’t make sense on item
-
Zash
semi-serious reference to git object
-
jonasw
hm, unless items from different nodes are batched in a single event
-
Link Mauve
I’ve never seen that done.
-
Link Mauve
But everytime I read this XEP, I learn new things.
-
jonasw
everybody seems to say that about '60
-
Link Mauve
And items@ver isn’t specified in the schema. :|
-
jonasw
lovely
-
Zash
https://xmpp.org/extensions/attic/jep-0060-1.7.html#schemas-event https://xmpp.org/extensions/attic/jep-0060-1.8.html#schemas-event
-
Link Mauve
Oh no, this is commented in the XML file.
-
jonasw
Link Mauve, where?
-
jonasw
ah nevermind
-
Link Mauve
Is it actually possible to have a <{pubsub#event}items/> with neither <item/>s nor <retract/>s inside?
-
Yagiza
Zash, that's implied
-
Link Mauve
“19:09:00 vanitasvitae> At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D”, yes, XEP-0246, XEP-0247 and XTLS. ^^
-
vanitasvitae
Link Mauve: yeah I think we talked about it right?
-
Link Mauve
Yes, on the last day, outside K.
-
vanitasvitae
Right :D