XSF Discussion - 2018-01-26

Fortunately, MUC is easy to implement. https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message

Do we have any XEP/way to do item ordering beside using a specific element (e.g. <order>123</order>) and a MAM query?

I don't think so, but just in case I've missed something

So, why is it that a group chat with jabber doesn't give me the messages that I missed when I come back online?

It seems there are some related mechanisms in place.

There are two mechanisms for that

And of course for some sorts of chat rooms in doesn't really make sense...

SaltyBones: it does if mam is enabled on the muc

moparisthebest, and the client supports it.

*and you don't want crypto*

that’s false

SaltyBones: nope works fine with crypto

OMEMO should work fine with archives

That's what I heard. :)

OTR won’t

Also pgp

gpg too, yes

Otr doesn't work in mucs at all

jonasw, but then the archive will contain the decrypted messages or something, right?

No

SaltyBones, no

Hm.

So what you're saying is: Everything should totally work. :)

iff both client and server support MAM

and it's enabled on the muc

I am currently trying to figure that out.

But neither gajim nor conversations seem to be very helpful. :)

And what about forward secrecy?

zinid, probably broken, cannot imagine any other way

no, that depends on encryption method

none with pgp, works as expected with omemo

are there any clients that can display if a muc has mam or is that serverside info only?

that is, each device can decrypt each message exactly once

clients know, not sure if any display

How will you decode a message from archive encrypted with forward secrecy?

(they have to know to know whether they can mam query or not)

wait is mam not the same as server side history?

as MattJ said there are 2 methods so depending what you mean probably not

you want mam though, the other isn't guaranteed to be complete

there are two MAMs?

who wants forward secrecy anyway?

it's even worse than cryptographic deniability.

dissidents so I hear

Ge0rG, almost nobody but a lot of people want it on principle, including me. :)

forward secrecy is actually useful unlike deniability imho

SaltyBones: a lot of people have no clue.

SaltyBones, method #1 is a simple cache of recent messages in the room. The MUC tends to send it to you by default, though clients can (and do) filter it

https://dymaxion.org/essays/pleasestop.html - "Please Stop Writing Secure Messaging Tools"

point being it works fine with muc + mam

Ge0rG, clearly written by NSA plant

SaltyBones, it's almost universal, but doesn't actually need client support - the recent messages are always just sent to you (most servers default to 20 or so)

Ge0rG, I would agree if I thought that one of them was good enough.

s/NSA/GOV_OF_YOUR_CHOICE_HERE/

SaltyBones, which is enough to get some context on an ongoing conversation

MattJ, yeah, that mechanism is pretty obvious in gajim...

OMEMO is bad because you can't bind a cryptographic identity to a JID in any strong way.

SaltyBones, there's a second method (MAM), which requires explicit client and server (i.e. MUC server) support, and supports fine-grained sync, ensuring that you can achieve a full sync of all messages that happened while you were out of the room

MattJ, unless the server keeps CSN and other useless things in the history ;-)

One client's useless is another client's treasure

Ge0rG, I think that article is mostly crap but I would be interested in discussing. ;)

> Ge0rG: OMEMO is bad because you can't bind a cryptographic identity to a JID in any strong way.

uh and what ways do allow you to do that?

I think, none actually

moparisthebest: things like TOX, where your ID is your public key

that's fine if you are talking about an entirely different protocol

Something something triangle

that eats battery and is unsuitable for mobile

IBE requires a trusted third party which I find generally undesirable

Zash: something something blockchain

BLOCKCHAIN!

The funny thing is, blockchain derivates are actually usefull for PKI

I can feel my synergies aligning already, lets get an IPO and some angel funding asap

Hm...I am totally in the mood for discussing everything but I have to get some more work done. :/

moparisthebest: I think it's possible to avoid battery consumption with help from very simple relays

I call those xmpp servers :P

though, not simple

moparisthebest: "simple"

https://www.wired.com/story/mobilecoin-cryptocurrency/

let me fix that title s/The Creator of Signal Has a Plan to Fix Cryptocurrency/The Creator of Signal Has a Plan to Finish Construction of His Money Fort/

cryptocurrencies are bullshit :p

moparisthebest: but I'm told he is a hero, you're just jealous

moparisthebest, SaltyBones: seriously though: OMEMO is attempting to work around the problem that JIDs are not cryptographic entities, and there will never be a perfect alignment of them.

if you want E2EE without meta data leaks, XMPP is not the right tool. Have a look at something like https://briarproject.org/ instead.

If you want XMPP, just give up hiding your metadata and accept reality.

And once you've realized that, the added benefit of E2EE is minuscule.

The benefit of e2e is miniscule when there is metadata leakage?

I completely disagree. :)

I’d argue that the benefit of e2ee should be miniscule since ideally we had friends&family servers exclusively

Agreed

I don't think it's completely pointless in any scenario, but trusted servers buys you a whole lot more

That's an interesting point...

This will not be the case, at least in a not-soon future D:

On the other hand some people really value anonymity, which goes in completely the other direction - we should just have an internet full of servers, random JIDs and use E2EE for identity proof and encryption

Given that most murders are committed by spouses or whatever maybe friends and family servers should be less trusted. :)

SaltyBones: so if I know my wife's password and lock screen pattern, she's still safe, right?

also related: https://dymaxion.org/essays/usecases.html

It's not a good idea to argue against securing one part of a system because another part of the system might be insecure. If your wife has an affair maybe she will change her lock screen pattern...

SaltyBones: in that case I can beat her up. (playing the devil's advocate here, obviously)

SaltyBones: also I can still see which JIDs are on her roster.

"So, who is sexy_patrick69@swissjabber.li?"

Come on, these are all incredibly weak arguments that you can immediately invalidate by yourself.

This is not a useful discussion. :)

How do you know you have to beat her up? Just because she changed her lock screen?

SaltyBones: sure

Maybe the guy she s seeing is a colleague from work and it s perfectly normal for them to talk

SaltyBones: how much do you know about abusive partners?

Abusive partners are not the only adversaries and abusive partners probably also come in all sorts of degrees

SaltyBones: so you don't even know the attacker model you want protection from?

I trust my co-admin not to read my messages I still prefer that he simply cannot when I use omemo

SaltyBones, yeah, I agree.

Even if I don't use OMEMO myself

I have a sufficiently good idea of my attacker model but it's not formally defined ;)

SaltyBones: I don't say that E2EE is generally bad. I merely say that it has a cost attached, and that cost is inability to restore archives, various synchronisation problems (why can't I receive messages) and multi-client woes.

SaltyBones: so for the general audience, OMEMO does more harm than good.

and I also like that even if my server gets owned I can still send account data and scans of legal documents to people without worrying where they might end up

And I even haven't started to talk about the two incompatible flavors of OMEMO.

Ge0rG, oh I completely agree that omemo isn't great but omemo is an implementation of e2e not the definition.

Actually, gpg probably has much better usability whilst also protecting against the attacker model we just discussed

SaltyBones: don't even get me started about the usability of GPG

:D

"gpg probably has much better usability" is not something anyone has ever said with a straight face before :)

only people who haven't tried ;D

SaltyBones: so you haven't tried? Noted.

"But I want OMEMO in the browser, and I want to access my archive!"

No, GPG is death by key management...

SaltyBones: OMEMO is also death by key management..

or death by `adb backup`, which is even worse.

Ge0rG, signal however, is not

and actually omemo works okay

you have to consider that even if you don't ever validate anything it still protects agains passive adversaries

SaltyBones: against passive adversaries who have admin access to your server and want to know more than just your metadata.

and then it's just a command or two to add another key to your identity.

Yes, and a warning will pop-up that you can chose to not ignore and also they cannot read the history...

And that's total shit, I agree.

My problem really is that with OMEMO, you have 3+x identities: your JID, your display name, and a number of device keys. ✏

and those aren't linked in any cryptographically significant way.

Actually, I don't care much about JID and username...but there should only be one key

Hm..what kind of linking are you thinking about?

One key => key management becomes a real pain

In the real world, people lose their phones

One key per what?

MattJ: yeah, but what about key cross-signing. If I buy a new device before the previous one is broken, I sign my new key with the old one and my friends auto-trust it

yeah, that

if

Is the JID encoded in the public key cert?

or can I use the same OMEMO key on different JIDs?

What we need is more X.509!

what's my identity? The JID or the pubkey?

Zash, wait here I'll get my pitch fork.

On the one hand you're talking about making XMPP easier to use. On the other hand you're talking about asking family members to perform key cross-signing

What is identity?

Your identity is the JID, simple

So just keep it that way

gngngngn

what

stop

the identity is the key!

:)

MattJ: "scan your old device with your new device to auto-configure your jabbers"

Ge0rG, the old device is broken, stolen or lost

Ge0rG: I do WHAT?!

Ge0rG: Can't we just use WhatsApp please?! That just works!!!

Yeah, or just get a pop-up: "You want to add a new device. Please confirm!" on the old phone

SaltyBones: yeah

90% of the phone upgrades in my family have been in response to breakage, loss or theft - not planned upgrades

MattJ, that's fine then just let them also create a new key....

MattJ: now we are back to the attacker model. Are we talking about trust-by-default in the general population or about secure messaging for dissidents?

I'm talking about the general population

"Where's my chat history???"

Niche markets will help themselves, they always do

E2EE just doesn't work for family chats.

Trust in the server, the server is good.

that's the next thing. The server can completely strip out the OMEMO identification on your comms. What then?

Use a different server and/or don't communicate

This is not a novel problem

Routers can (and in some cases do) drop TLS handshake packets

Yes, but OMEMO isn't mandatory on XMPP :P

Ge0rG, e2ee seems to work for whatsapp tohugh

And signal

and for my bloody family even omemo works ;)

Because no verification. And no PEP!

of course I just tell them to shut up when they complain ;)

jonasw: "works" is relative, though.

Kev, inhowfar?

Holger, PEP?

In as much as the whatsapp multiaccount story is far worse than XMPP's, and I hate losing messages, and etc.

SaltyBones: Well OMEMO uses PEP for distribution of pubkeys, and that keeps falling apart.

jonasw: https://www.reddit.com/r/whatsapp/comments/68sgmx/google_drive_backup_encrypted/

(Plus the recent vulnerabilities in it)

whatsapp loses messages?

that’s new to me

It does when you lose your phone.

hehehe

https://www.reddit.com/r/whatsapp/comments/68sgmx/google_drive_backup_encrypted/dh1w7j3/ "This is where you are wrong"

-xkcd 538

heh, I had never seen the alt comment

Bunneh: Meh

Where is your wrench now?

even in the case of trusted servers, I guess all servers are secure and all software well configured? that's not exactly the impression I get

my xmpp server is in a closet in my house that I'm pretty confident is physically secure, and I like to consider myself competent enough security-wise that no one can hack in, but everyone makes mistakes, and no doubt some software has bugs

e2e protects against that too

even just the passive BTBV variants

Eww all your stanzas pass through a closet?

they do :)

Oh the dictionary says "closet" != "toilet".

Ah the dictionary says there's both meanings :-)

The German "Klosett" is always a toilet.

hmm never heard of that meaning, language, fun stuff

I mean where you'd normally hang clothes in a bedroom :)

That's ok then :-)

though, an xmpp server inside a toilet would be EXTRA physically secure

I mean, you can grab it, if you want to, be my guest

moparisthebest, secure enough if you have no friends

I just got around to reading your "Please Stop Writing Secure Message Tools" blog thing Ge0rG https://dymaxion.org/essays/pleasestop.html

but it seems like, don't write them unless they check all these boxes

and xmpp checks every single box

except it could maybe deal with a little less metadata, but even then, it's scattered all over vs in one silo

something something threat model

that crap where if the NSA isn't after you you don't need encryption is just that, crap, everyone needs privacy

and if it's a little less user friendly than not encrypted, work on that, see letsencrypt for example

moparisthebest, do those people dumping their lives in instagram need privacy too?

privacy is a broad term

sure, you choose what you want public or not

zinid, maybe they live double lives, and one of them is protecting the other by sending crap on instagram!!

who knows

moparisthebest: If someone says he doesn't like Bananas that's crap, everyone does!

that would be a preference vs a statement of fact I guess

Sure sure.

"everyone needs privacy" sounds like a statement of fact ;)

the problem is in definition of privacy

it's identical to the TLS vs plaintext debate honestly

and that seems fairly settled nowadays that everything needs to be TLS doesn't it?

It's not identical in the case of TLS for c2s.

a valid argument is/was that TLS is harder than plaintext, has useability problems etc etc

At least not when using PLAIN SASL.

moparisthebest, TLS is slow shit, I use plain http wherever possible

haha but you are wrong

TLS is faster in many cases nowadays

It's not "everyone needs privacy", it's > No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.

moparisthebest, sure, you know better

It's a human right. Whatever the definition of privacy is. ✏

zinid, don't take my word for it https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/ https://istlsfastyet.com/

plain http today is slower than https, there is no debate about it

that's why I use http on some sites, I'm just blind and cannot see how https is much faster

but is it fast enough to counteract the ever increasing bloat?

... no, it just encourages more bloat

can't have fast things

says a guy who enjoys shuffling XML streams around... :)

pretty sure my messages aren't in the order of megabytes

neither are my webpages; they're still ~20% faster if I'm using TLS.

I've been browsing with JS disabled, or selectively first-party-only enabled, and it has been a pretty great experience.

my 1-hour poezio's XML log is 300kb, horrible bloat

Oh, TLS won't speed anything up on XMPP, but it's not slow either. Basicaly negligable.

and here come servers where you need twice RAM to support TLS connections

You really don't

Machines are optimized for it these days; TLS's extra resource use is basically negligable unless you have a much bigger server than I think you do.

even google, which has servers way bigger than any xmpp deployment, says it's essentially no overhead

ever tried to connect 1M of XMPP sessions?

and that was years ago

with TLS or without

TLS

You are both wrong. More than negligable, but not double memory consumption.

TLS handshakes are quite the CPU hog too.

moparisthebest, because HTTP doesn't have long-lived connections

the long lived part really is 0 overhead

yeah, sure ;)

any overhead is just on setup, so from that perspective, http over TLS is more overhead than xmpp over TLS

and since https isn't a problem, xmpps certainly isn't

even nginx author says it's about 50k-100k overhead per connection

zinid, I mean you were right in 2005 for sure, maybe even 2008 or whatever, whenever aes-ni became a thing

there is a recent issue in our bugtracker where a guy complaining about huge memory consumption when TLS is enabled

30Gb overhead

on 1M connections

but, possible, 30Gb is nothing for google

is that a public bugtracker? sounds interesting

sure

it's on github issues, but I'm too lazy to find it, anyway, Holger will not let me lie, he laughed at the issue too ;)

What's the total memory usage?

iirc when google forced https for gmail the usage increase was like 1.2% and that was pre-http2

can't actually find that right now...

SamWhited, 70Gb or so, I don't remember actually

https://github.com/processone/ejabberd/issues/2062

is that it?

yes

impressive

how much memory does the rest of a connection take?

what % is 50kb

it's highly depends on usage, roster size and so on

*it

That does seem high; 50k of overhead per connection is much more than I've ever seen; not sure what that could be.

if a non-tls session takes 1mb of ram and tls adds 50kb, that's 0.09% increase?

I think he counted wrong, I'm trying to calculate now and I get numbers far above 90Gb if I do 2Mx50kb

yea that's true

anyway, 50-100kb is a typical overhead I see in stress tests, so...

https://www.zash.se/prosody-graphs.html .... is that like 15kb/conn for tls? I might have forgotten how to read those graphs

Dat CPU usage tho

but really the % matters, if that's only a 0.09% increase well...

moparisthebest, that's not 0.09% increase, in production we offload TLS because huge RAM machines are expensive, so we split the RAM between the machines

First random Google hit: > OpenSSL tends to allocate about 50KB of mem­ory for each connection. https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

why would we do this crazy shit if there was negligible overhead?

Something something release buffers?

how much do you allocate for a regular XMPP connection though is what I'm wondering

Zash, the option is set

my hunch is it's so much more than 50kb that 50kb is negligble

Isn't that option for freeing memory on *idle* connections?

moparisthebest, for empty roster c2s it's no more than 50kb in fact

moparisthebest: On the two servers I'm involved with it's about 300k, but those are with all bells and whistles enabled (MAM and whatnot), so it's probably less elsewhere.

It's really hard to say, because there is a crazy garbage collector in Erlang doing some weird shit

not to mention how great openssl is when you try to connect 2M :)

you need to patch it, or else it will spend most of the time in locks on a machine with a lot of CPUs