XSF Discussion - 2016-05-18

if only we could make XMPP use this new cipher "We created a cipher that is 6,000,000 times stronger than current data security, as proven by algorithmic mathematics." https://www.kickstarter.com/projects/datagatekeeper/datagatekeeper-the-first-impenetrable-anti-hacking

yikes, can anyone read that without cringing? :P

Not even gonna try

is it my copy&paste-fu, or is that link a 404?

oh, it's the former.

you know you want to read it Zash haha

moparisthebest: I wonder if the icon is supposed to represent a trojan horse or my little pony.

Ge0rG, both

This is the Total Data Protection! /:=O

That one is so hyperbolic.

XMPP Compliance Suites 2016 <3

would be really nice to have the validation system to promote the apps that are compatibles

Just updated to add a mobile compliance suite as well; suggestions for what should go in it are welcome: https://github.com/xsf/xeps/pull/185

Probably going to add stream compression, EXI, and push notifications at least at various levels.

For Movim it's a bit weird actually, because I'm not really a web client, but not a "IM" client as well

Is movim that social networking thing?

SamWhited: Don't we consider stream compression horribly insecure nowdays?

SamWhited, yup

basically it's a "webmail" but for XMPP

Zash: probably, I don't buy it though as long as you do a full flush on stanza boundaries

I don't buy that it's a problem, that is.

I guess that will probably come up when the discussion about moving it forward happens though, so good to start thinking about.

Well it's gone from the next Prosody fwiw

SamWhited: I don't know whether or not it's a problem, but it doesn't sound essential for interop/UX to me.

Holger: It helps a lot on mobile when you have a X000 person roster.

You have too many friends.

SamWhited: Even with various CSI optimizations?

edhelas, Movim definitely is both a web client and an IM client.

Coworkers, but yah, we (Atlassian) aren't even one of our (HipChat's) bigger groups.

Zash: Not sure about that; wish I could convince them to let me deploy my implementation.

Link Mauve, yeah but all the XMPP part is done server side, with a stable and good Internet connection

edhelas: Does Movim not make an XMPP connection to the server?

Holger, I have ~300 contacts in my roster, some clients really have issues to process it :p

SamWhited, it does but server side, basically you have

User Browser <- HTML + Websocket -> Web Server <- Pure XMPP TCP/TLS -> XMPP Server

edhelas: I guess compression won't help those clients though :-)

edhelas: Yah, if it makes an XMPP connection to the server, I'd say that means it fits in the web compliance category (in the sense that you'll need either BOSH or websockets to connect, and you'll have to implement the XMPP subprotocol of one or the other presumably)

315 here, and my main client is really slow at processing their presence. ^^'

Unless your HTML+Websocket connection isn't XMPP? I'm still confused.

Everyone has more friends than me.

no it's pure "web" websocket, there is no XMPP at all browser side

as I said, Movim is a "webmail" for XMPP

Oh yah, wouldn't apply then I guess

FWIW, compression is fine and perfectly safe in some cases; but they're oddball ones.

ok :p

Link Mauve, roster + presence processing need to be really well doneif you have a huge roster. It took me some time to have nice performance on Movim, now it process the ~500 stanza of the login in less than 1sec. All in pure PHP :)

the roster is actually read in one time and saved in one request in the DB

As it should be. If you ever find yourself writing "for whatever { dbcall }" you're probably doing it wrong.

Build the query, then execute, or you're going to have scaling problems later :)

edhelas, I expect your parsing to be way less heavy than slixmpp’s. :)

Also, Python is slow.

:D

I still consider stream compression essential for mobile connections

Also I've been working on Smack droping the compression dict state, not only stanza boundary, but on channel change. Where "channel change" means that the recipient bare jid has changed. I believe that this is the best trade-off between security and efficiency

Happy to be proven otherwhise and told if this still would be a security issue

What Flow said ⤴

s/not only stanza boundary/not on stanza boundaries/

the idea is that you can keep the compression dict state as long as you are sending stanzas to the same entity

I’d be interested in having that in Prosody.

Especially for s2s, since broadcasting a stanza to many people is very slow on ADSL.

And very often you send many stanzas to the same server in a row.

Even better, many similar stanzas.

Compressing single stanzas could allow attackers to discover your real JID to others in semi-anonymous rooms if they can observe the encrypted stanza size.

s/to others/

But that's very little payoff for how much access you need.

xnyhps: So no big worries with having compression this way from your side?

You can't easily detect if the server is doing the same, so I still think it's a bad idea.

well we coud register a new compression algo like 'zlib-secure'

I still think you can win a lot more (and actually reduce processing time and information leakage) by making sure stanzas that are sent simultaneously get into the same TLS record.

With any relatively modern ciphersuite there's at least 41 bytes of overhead per record, the maximum would be ~85 bytes with AES-CBC + SHA384.

Agree about sticking stanzas in the same TLS record, but I very much doubt you can convince most clients (or servers, for that matter) to try and optimize at that level. Would love to be proven wrong though (hint, hint, client/server developers)

I'm not sure a zlib-secure algo is needed; just require it in the spec in general and if you implement that version of the spec assume it's being done.

(if it's not being done, that's a bug but it could equally not actually be happening if they advertised zlib-secure or something)

stpeter, what are the plans for https://github.com/stpeter/xmppdotnet/ ? expanding the team that processes those PRs?