jdev - 2023-03-14

am i right to think that xep-0116 has been superceded by omemo or are they unrelated

Esessions? Yeah that's ancient and obsolete

for context im reading through existing security-related xeps before reinventing any wheels if i draft my own standards

cool thanks lol it looked like that but i couldnt be too sure cus the summary was a bit indecipherable for me

Maybe something for Editor to formally obsolete even

yeah it may be helpful to have a note for what active standard(s) replace it

in a nutshell i'm tired of hearing about what everything else has but xmpp doesnt, although "everything else" tends to be less solid of an experience than this, so maybe theres some easy (and not so easy) stuff i can do both on standards and client/server dev side to bridge the gap

voice/video i think was the last milestone i can think of

which is a good one, ive used it on my phone to call friends on the road when we were planning to meet up lol

opal, I learned that it's useless to argue with people who make such statements, usually they already made up their mind and will find another reason if contradicted

im only focusing on the valid shortcomings ive seen of xmpp

things i'd want too

like, with how voice/video and e2ee existed over a decade ago in XMPP

maybe not widely implemented, but existed in some form

was voip ready-to-use a decade ago though? afaict gajim had it for a while but it worked poorly

succumbed to code rot probably lol

I remember testing voice and video with Gajim in like 2010

yeah i tried much later in gajim and failed to get it working right

I could make video calls from my N900 phone over XMPP around that time, all your arguments are invalid!

lol

Of course, nobody cared about video calls, so nobody maintained the code and it decayed

Further evidence that those feature based arguments should be ignored

Nimbuzz had a voice transport to/from Skype in ... well before 2010.

my biggest personal complaint is with how unwieldy omemo is; olm in matrix tries to do something better with cross-key signing but thats ugly too

as for the easier side of things: arbitrary message editing / replies / redacts are a common enough ask

and all that needs is to refer to specific message ids for those commands

opal: Both OMEMO and (Meg)OLM are based on Signals protocol. But MLS is the future!

https://en.wikipedia.org/wiki/Messaging_Layer_Security i assume, and not major league soccer lol

I'm reviving a server-sided EXI implementation. Basic functionality seems to be working fine. I'd like to test this against a client that's not written by the same authors of the server-sided implementation. Does anyone have a client (or library) that does XEP-0322 ?

oh wow dino 0.4.1 completely ignores my gtk theme cool

and now i see the reaction popup nvm

its different from the emote menu

and im talking in the wrong channel lol

> and im talking in the wrong channel lol i guess replies are a thing though now, lets see how this looks ↺

finally, the one feature that was holding XMPP back! oh wait, now it's something else

i dont need the sass from you, ive successfully brought people onto xmpp who didnt use it before

save it for someone relevant

don't mind me, I'm just bitter after some 15+ years of hearing things like that

i know you are but im bitter after years of hearing "dont do things because they arent worth it"

so we'll butt heads at this rate

I like to do things instead of arguing, so that's what I did

good philosophy

opal, re encryption, maybe join xmpp:e2ee@muc.xmpp.org?join

thanks i will

> I'm reviving a server-sided EXI implementation. Basic functionality seems to be working fine. I'd like to test this against a client that's not written by the same authors of the server-sided implementation. Does anyone have a client (or library) that does XEP-0322 ? We have now blogged about this effort: https://discourse.igniterealtime.org/t/developing-openfire-efficient-xml-interchange-exi-functionality

Cool. Great work.

Thanks. It's pedigree might trace back to people close to you. :)

You mentioned a student - I think this was him.

Yes, correct

Sent him the link also. An unexpected but happy surprise, I’m sure.

As you write, it would be good to do interoperability-testing, also in a federated environment. Need to find a slot for that.

I would also like to encourage an experimental UDP/DTLS-binding to the broker. That, in conjunction with EXI, would be very interesting.

I can assist as mentor, if needed. Also help editing/writing a XEP for such a binding.

A server with such a binding would be able to support millions of online devices (depending on actual amount of device-data, of course), even on a modest computer and resource-constrained network. A serious challenger to CoAP and LWM2M.

Perhaps something for summer-of-code? (Or some master students) ✏

I'd welcome that - although I cannot commit to mentoring myself

This years GSoC might already be underway though?

Ah, proposals can be submitted until April 4th, it seems. So we might be able to get in, if things work out.

Perhaps I read this wrong:

https://developers.google.com/open-source/gsoc/timeline ✏

"mentoring organizations"

Would the XSF be one of those?

The XSF got accepted as a mentoring organization this year.

ah, ok, I see

guus.der.kinderen, Peter Waher: any thoughts about whether EXI might be vulnerable to CRIME-like attacks?

https://summerofcode.withgoogle.com/programs/2023/organizations

moparisthebest: I have no idea.

> I would also like to encourage an experimental UDP/DTLS-binding to the broker. That, in conjunction with EXI, would be very interesting. Peter Waher: what binding? Is it still relevant with QUIC existing?

Sufficient with UDP & DLTS directly; more light-weight.

Regarding CRIME & EXI: Not sure there are any secret web cookies involved… While a speed session does not list which namespaces & schemas are to be used explicitly, this is for speed only, not meant for hiding which schemas & namespaces are used.

EXI is not meant to hide information. The DTLS-layer does that. And while the DTLS-layer uses such cookies & session counters instead of socket connections, they are not included in the EXI-layer (as it is built on/for TCP initally).

Peter Waher: what makes you think UDP & DTLS is lighter weight than QUIC ?

It might be an interesting side project to study as well…

CRIME explicitly leaked data from inside the TLS connection, that was the bug

So saying "exi is inside an encrypted stream" means nothing

If you have compression and mix sensitive and attacker controlled data, there might be CRIME-like bugs.

deflate/zlib etc kind of compression

See https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/

Well any kind of compression, of which exi is a kind, so implementation details matter, hence my question

EXI differs from other compression methods, in that it retains the semantics of the XML

while other typical compression methods work on tokens, not related to the XML syntax

Compression based on fixed dictionaries should be relatively fine, and simple things like FunXMPP

They are not fixed dictionaries either. Instead a state-machine is built based on schemas the client understands/want to include in a session

XML is then normalized

and encoded, by evaluating the number of possible options available in each step, during serialization

I vaguely recall you could use deflate or something with EXI?

Not by itself

you could add it as a layer

for transport

but EXI can be seen as normal XML, except it’s serialized using minimum number of bits, as deduced from schema files and normalizing XML and alphabets.

So it doesn't take transport-layer input

And it does not consider schemas to be secret

Peter Waher: If you're interested in getting under the XSF umbrella for GSOC, then this page is of interest: https://wiki.xmpp.org/web/Google_Summer_of_Code_2023

I can facilitate, but cannot commit to mentoring.

> Peter Waher: what makes you think UDP & DTLS is lighter weight than QUIC ? Any thoughts on this one?

The main difference is that resource constrained devices are typically datagram-oriented, not stream-oriented, even though DTLS permits fragmentation and reassembly of larger blocks of data. Protocols for such devices are therefore already based on UDP/DTLS-based protocols. This means that communication libraries and operating systems already support this. (XMPP in a sense is BTW also easily made into a datagram-oriented approach, with its quite small minimum(maximum(stanza-size)), if order of stanzas is ignored, which Google Talk suffered from.) So, available communication libraries typically support UDP & DTLS. Availabe/comparable protocol competitors are based on UDP datagrams and DTLS. QUIC attempts to solve similar problems as UDP & DTLS. QUIC is therefore only comparable to UDP/DTLS, if this standard library support for UDP/DTLS is also removed at the same time, and if no protocols based on these are supported by the device (otherwise QUIC represents an addition to existing code, making the device less light-weight, not to mention more work intensive, having to maintain parallel stacks updated over time). This is the point.

Interesting side note: EXI is very resource conserving for devices, as collections of schema files can be converted to compilable C-code automatically, and stanzas are therefore easilly serialized into binary blocks, easilly fitted into single datagrams, and vice versa, a datagram received is easilly decoded in the app, via the same automatically generated code. For the EXI case, a datagram approach is therefore favorable, compared to a streamed approach. One of the problems solved in 0322 is how to separate the stanzas in the stream. Over UDP & DTLS this is not necessary, as datagrams separate them naturally.

This might also perhaps be seen as a vulnerability in some cases (see CRIME above), in the sense that observers can observe sizes of datagrams, not readily sizes of stanzas in a stream. For resource-constrained-devices, this is typically readilly available anyway, as it’s easy to learn the sizes of automatically generated repetitive stanzas from machines.

Hope this answers the question

So tiny resource constrained devices support multiple protocols at the same time, instead of just XMPP?

Typically, a device RTOS supports multiple IP-based protocols out-of-the-box, yes. As do communication libraries. Unless you choose to build everything from scratch. This also happens. The smallest XMPP-implementation I’ve seen was 12 kB, which was impressive.

Also is that still a thing? A sub-$1 esp8266 will do real XMPP over TLS over encrypted WiFi just fine

WiFi is not considered resource constrained

btw

Also, you have two ends: By using DTLS you avoid the socket connections that are quickly consumed on the server end, if many devices are connected.

resource constrained typically refer to one (or typically more) of: 1. Power consumption 2. Bandwidth 3. Memory

(with 4 MB Flash you typically have no problems building a complete communication stack. Resource-constrained devices typically do not have such resources; they are often battery-powered, and must remain on battery for long periods of time. XMPP is not the first choice in such cases, but with UDP, DTLS (with PSK instead of X.509), EXI, it could be.)

XMPP has exceptionally many other benefits its competitors do not share. ✏

Peter Waher: it's not just flash, its also RAM

Yes

(EXI C-code, and datagram processing, is very RAM efficient also, btw.)

in some cases, i would assume you have to write the XML parser in assembly

yes, of course, or as an efficient C-code state-machine

A resource-constrained device would probably not implement a generic DOM

yeah

what is this resource-constraint device, if it doesn't support WiFi, is it meant to be connected via wired ethernet?

There are many alternatives

Fore more references, you can check: CoRE, CoAP, LWM2M, 6LOWPAN, IPSO, for example. This would be the main competitor. It’s very successful, but suffers from tight coupling, and is difficult to extend

XMPP offers a much wider and richer networking environment

(especially if its weaknesses are resolved: verbosity, socket connections, power consumption, etc.)

Many (or most) of these are resolved using EXI over UDP/TCP.

It seemed like the only reason to prefer udp+DTLS over quic is "maybe library support" ?

moparisthebest: can quic be implemented in a resourcee-efficient way?

It cannot still compete with CoRE & LWM2M, if only byte count and uW is counted. But it provides a completely different set of possibities for interoperability, extensibilty, privacy and security compared to what CoRE-LWM2M can provide.

Anyway what I mean is there are plenty of very small, very cheap, very light power usage chips today that can just run regular XMPP

I'm not sold that anything needs something lighter than regular XML and quic today

yes, it is getting better. But the requirements are also moved further…

10 years ago? Sure

> moparisthebest: can quic be implemented in a resourcee-efficient way? techmetx11: why not? It's just UDP with some TLS, basically