XSF Discussion - 2019-08-17

it is getting ridicoulous with disco info

i just added a feature, and this triggered hundreds of disco info requests

this behavior is not scaleable

we should do something about that

server-side caps optimization

lovetox: what's the use case?

cineva roman pe aici ?

Daniel esti roman ?

david esti roman ?

admin1234 test

Kev help my please

ralphm, im not sure what you mean

not getting ddos'ed when you join some mucs?

There is an experimental prosody module that will cache and auto deliver the disco#info for local clients.

Unfortunately it's full of race conditions and/or doesn't work on prosody stable.

lovetox: I didn't understand what you meant by you having added a feature.

But now I do

ralphm, its even worse

lovetox: it's also the cause of a significant number of mobile wakeups, because there are also clients that join after you.

because of a unfortunate example in the disco spec

client add version numbers under the identity name attr

means every new version of that client, you get spammed with disco info

even though nothing changed about the caps

This is why I'm sceptical of version numbers in disco/caps

in my opinion they should not be there, and nothing mandates that a version number has to be there

its just devs put it there because its in one example i think

we have 0092 for version

there is no need to put this in disco info

Yeah. How often do you really need their version number?

if i need it i request it

of course it would be nice to have it in there, but the costs outweigh the benefits

and yeah i really almost never need the version number

only if i display some details screen of the contact

and if i open that its totally fine to send a 0092 request

lovetox: you could submit a PR fixing the example

But then it would have to come with a note to discourage the version?

lovetox does in gajim exist a bookmark export? jabber.de lost all bookmarks of some users during a downgrade in july I think. In Berlin's Meetup MUC was discussed that so such export exists yet. ✏

Also, I think in practice this isn't as much of an issue: the hash is cached for all users, so only the very first encounter of a new hash will cause a disco request.

As a developer, yeah, that might be less nice.

I think lovetox gets the worst of it because he is the one to first have a new hash

But I've made a note to remove the version from Conversations' cache

From disco info, you mean?

eevvoor, there was a plugin once, but it didn't get ported to 1.0 I think

wurstsalat, ah that is not long ago. cool, so there is something to build on.

ralphm: yes

lovetox: which example is it?

eevvoor, https://dev.gajim.org/gajim/gajim-plugins/tree/gajim_0.16/offline_bookmarks

thx wurstsalat

ralphm, https://xmpp.org/extensions/xep-0115.html#howitworks

scroll a bit down

yeah and i guess as developer im getting the worst of it

but in Gajim exist plugins that alter the disco info to announce support for some feature

But either way a server caching disco infos would be great

i dont see any drawbacks

lovetox: race conditions when you change the caps at runtime

do you have an example?

i dont see a problem there, server gets a request for a hash, either he has it then he answers, or not then he routes the IQ

You're supposed to include the caps hash in the @node when querying, so that should be detectable

Zash: some clients ignore that @node

Ge0rG, how is this relevant?

"Some clients are broken"

And IIRC we have the issue that the node value can be gamed

ok you lost me

Where's caps 2.0 when you need it

lovetox: https://xmpp.org/extensions/xep-0390.html

https://mail.jabber.org/pipermail/security/2009-July/000812.html

https://modules.prosody.im/mod_inject_ecaps2.html

The implication is that you must not use the cache across JIDs

Screw that

Ge0rG, huh? with XEP-0390 it should be safe, no?

The whole idea of CAPS is that the hash is not related to the JID

jonas’: I think so. Did you ask waqas yet?

What would you gain by such an attack anyways?

ralphm: the JID is the security boundary in this case

Ge0rG, I did

jonas’: did he answer?

I don’t recall

The XSF needs a new seal of approval, "Verified by waqas"

there is not a single security relevant feature in disco info that comes to mind, that usual clients currently use

and 0390 is save against all the attacks mentioned?

it should betm

at least as long as we stay on XML 1.0 :)

from a quick read, it seems not much work client side

jonas’, what happens if we don't stay xml 1.0?

flow: is there ecaps2 support in smack yet?

flow, then the control characters used as separators become valid codepoints in XML (1.1) character data and are thus unsuitable as separators :)

(for the hash function input)

Then what? DER?

Or other TLV-ish thing?

prefix them with NUL should be safe

Is NUL illegal in XML 1.1? I anticipate that class of bugs.

jonas’, why do we need a separator?

its not like we are parsing the string we create again later

No, but if you can create ambiguity, you can poison the cache with junk data

ah i get it

hm

but then it seems better to take < as separator but make sure every value

as it will always be illigal as a value

lovetox, < can easily be contained in form field values

only as lt or?

not as <

lovetox, not to your application.

Ge0rG, yes, NUL is illegal in XML 1.1

lovetox, we need to look at the codepoint representation, not at the wireformat. the wireformat *could* be littered with &#number;-based escape codes creating *lots* of ambiguity and breaking the hashes. not to mention that many XML libraries won’t even give you access to that.

you mean the lib converts &lt; to < before you have access to it?

yes this would be a problem

I sure hope the library does that, just like I sure hope that it does the reverse path

never thought about it, it just works :D

but yes i think it does also in my case

so, yeah, you need to use a codepoint (or sequence of codepoints) which is invalid in XML character data as separator

go-to approach which is safe for XML 1.1 would be NUL + something

I think it is unlikely we'd ever switch to 1.1.

me too

jonas’: could you make ecaps2 future proof by prepending NUL to each separator?

Ge0rG, it’s in the queue

I might actually have the diff somewhere