XSF Discussion - 2020-03-10

jonas’, what are your plans wrt XEP-0390?

Is it planned to stay compatible or do you want to change things?

For a new client which doesn’t need to be compatible with anything else, can I require it instead of 0115?

I remember we discussed some missing features in XEP-0390. Not sure if it went to mail-list

Link Mauve, I think it needs some breaking changes

though I don’t recall specifically what those were

Ok.

I’d like to become author for XEP-0284 btw.

You need an ack from the author? How does that work? Council if no reply from them after some time?

authors*

pep., effectively

Link Mauve, can you PR?

Sure.

I have other changes to do too.

:)

Just that it's the best way to get things to move

yeah, if we have a PR to look at, we can track the authors responsiveness, and if it is lacking, we can make you author

And what do you do if you have an author, but you disagree with them on some important architectural points? Fork the XEP?

I guess that's up to the author to know what they want and accept/refuse new authors

And yeah you'd fork the XEP if you really wanted.. ?

Not sure where council would stand here

Syndace: "GCM is not meant to handle larger amounts of data" what do you mean?

moparisthebest: GCM mandates to not return any of the plaintext until the auth tag is verified. This means that conforming implementations have to keep the whole plaintext in ram

I don't think so

You can/are supposed to chunk the data I think

See the Conversations thing that you just helped Daniel fix :D

You can just split it into smaller chunks

But it doesn't matter. The other two points are correct

And more important

Sure, you can also just use CBC

The problem isn't solved by cbc

Do you output unverified CBC decryption? You shouldn't

We use HMAC

Right, gcm is just hmac but built in so you can't use it incorrectly

then consider that point of my mail as invalid

The same restriction applies, you shouldn't use the result of the decryption unless the hmac is valid

pep., jonas’, here: https://github.com/xsf/xeps/pull/904

So you must keep that chunk in ram until you do, in both cases the solution is chunking

The "single primitive" is still a good argument

Just means you have to be super careful about the hmac...

Also I think GCM impls are not known for being bug free and super compatible

Well to be fair with gcm you have to be careful with the Auth tag

And both old old omemo and http upload do it wrong

I guess you always have to be careful with crypto

I think aes-gcm is required for http2 TLS, pretty compatible

If you use the correct length IV

Which obviously isn't obvious :)

Do you encrypt then hmac or hmac then encrypt, that's the real gotcha when not using authenticated encryption modes

encrypt then hmac

...the same way it's done by double ratchet

So you can verify the hmac before you even try to decrypt

But that means for large data you still need chunked, because the hmac is at the end, so you buffer encrypted data before getting to it, verify, then decrypt

yup, the description of the message decryption algorithm also lists the hmac verification before the decryption

fun

moparisthebest: well we encrypt stanzas so size limits apply

pretty sure a single stanza can fit the ram

Hehehe how sure are you :)

moparisthebest, did you submit your updates on '368 already?

No, still need to...

alright, then I didn’t miss it

> Hehehe how sure are you :) not sure enough. Noted as something we have to think/talk about again, thanks for the input.

to play it safe, a Full Stanza Encryption implementation can’t generate stanzas over ~7 kiB (decrypted) either way

I mean, stanzas are pretty damn certainly under 1 MiB in size, but still there are theoretical edge cases of IoT devices wanting to use OMEMO or something...

Oh is that so? cool

because 10 kiB is the minimum stanza limit defined in RFC 6120

not that anyone enforces that

I mean your average PEP-based avatar is way above that already

s/ki/k/

so my comment is pretty useless, but alludes to a general issue: there should be a limit or (cross-stanza) chunking (which then sounds awfully like sending stanzas via JET-encrypted IBB)

Anyone got stats on avatar sizes?

Zash, I have for MUCs ;)

(or, could have. I scale them down on ingestion) ✏

Syndace, actually, how about implementing FSE as JET-encrypted IBB?

I don't XMPP, what is IBB xD Heard of JET at least

In-Band Bytestreams

uh huh

https://xmpp.org/extensions/xep-0047.html

"sessions" looks like it's synchronous/requires both parties to be online

ahh, right

that’s gonna be a deal-breaker

would’ve been fun tho

so you need to either specify some kind of chunking (then the question: how to deal with missing chunks? see the vulnerabilities in IP fragmentation implementations to get an idea of why this question is important and non-trivial) or set an upper limit which is sane

chunking is a big nope from my side

so much complexity for such an edge case

xmpp.net server test is soooooo slow

servers are already encouraged to do stanza-too-big stuff

Syndace, so we end up with Path-MTU discovery in XMPP :D

lovely

it is amazing how problems replicate on each layer of the stack

it cant even take my request to check a new server

I'm about 98% sure all clients would crash and burn if a server sent them too big of a stanza

for some definition of too big

yeah ✏

when I started aioxmpp, I asked, and people told me to trust the server on that one.

and I think that’s a sane way to look at it

obviously it shouldn’t allow you to RCE, and you may handle it more gracefully than OOMing, but what are you gonna do?

*maybe*, but RFC-wise does anything really stop a server from just streaming stanzas around?

I'm not sure that's on us to solve

lovetox, it throttles a lot in order not to take down any server, no matter how underpowered it is.

once you have who the stanza is addressed to, you don't really *need* to buffer it in memory anymore as a server right?

just read a bit and send it right out the other end

moparisthebest, you still need to do buffering to synchronise when multiple entities want to same to the same entity at the same time

I suspect no servers in the wild are written this way, but they could be

you also have to reject stanzas which are invalid XML

(as per a MUST in RFC 6120)

so you have to at least de- and re-serialise them

hmm, well that does imply buffering entire stanzas then

(of course, you can do this by simply streaming SAX events around, no need to build the full tree)

ah yeah, you have to at least keep a copy

damn xmpp.net server test cant do direct tls test ..

can somebody test direct tls on movim.eu

correct

"test"?

it does send invalid tls handshake for me, and i want to find out if thats my lib or a problem on the server

s2s, c2s?

c2s

does it listen on 443? if so you can test the TLS bit with ssllabs.com

no

149.210.220.39:5223

thats the address

2020/03/10 18:58:09 failed to probe c2s to xmpp:movim.eu: tls: first record does not look like a TLS handshake

lovetox, ^

my blackbox exporter agrees

openssl s_client agrees, too: 139993024365760:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:

yeah, that’s plain XMPP

you can also do https://nl.movim.eu:5223/

sending anything with ncat gives me a not-well-formed XMPP steram error

do http:// instead

won't let me, HSTS ?

pity

then use ncat :)

but yes, mostly that works too :)

it’s a plaintext XMPP port, not direct TLS

yep that record is wrong, dino will likely fail to connect ever too

(yet another reason TCP connect success should NOT be a criteria for not falling back to next SRV record)

yes moparisthebest a user reported this today

and now he cant connect, because i dont try the others ^

who's responsible for movim.eu ? edhelas ?

yeah i notified him

but see moparisthebest nobody would find that error

its a thin line to walk

well, user would probably have preferred to just be connected though

you dont want to shadow all errors, and you dont want to make your users mad

you could maybe report connection errors anyway?

yes, i agree in this case user wants to connect and does not care

"hey we failed to connect to X so now we are connecting to Y" or something

you won't hear any "UX is easy" arguments from me :)

lovetox, it’s the operators responsibility to monitor

the tools are there

10 day TTL on that SRV record, so the fix needs to be make that a direct TLS port, not remove the SRV

the first error I showed you is from a tool to monitor c2s/s2s connectivity on both direct TLS and STARTTLS. it can even do XMPP pings if you give it credentials. it’ll also check whether expected SASL mechanisms are there.

hm

maybe I should take the search.jabber.network domain corpus and scan all the SRV endpoints and notify operators about failures.

or at least the corpus of domains affiliated with the top 100 or so rooms

I was going to say, a tool is good, but you need another off-network server to be able to run it on for it to be real useful most of the time, not all admins have that I guess

moparisthebest, not really

most of the time, failures discovered by monitoring from the outside are not something you can fix either way

if you only have 1 server, running the tool and xmpp server on the same machine isn't ideal

it’s not ideal, but it would definitely have caught this problem

certainly better than *nothing*, and yes

it will also catch the issue when the server runs OOM

and crashes

it will catch most of the things you can fix locally

it won’t catch when the entire box goes down, but chances are you’ll notice that either way

(and you can ping-probe the up-ness of the box cheaply from the outside)

also, maybe I should start offering XMPP probes to others. it’s cheap for me to do, sending emails on problems is cheap too

on my giant todo list is still such a tool/service but also checking things like "is alpn required" and such

moparisthebest, feel free to include basic checks in this: https://github.com/horazont/prometheus-xmpp-blackbox-exporter

"is SNI required" as well, similar to ssllabs

"is X required" kind of stuff isn’t interesting for continuous monitoring though

(oftentimes)

yep I agree, it's pretty helpful when setting up though

true

extending/rewriting xmpp.net would be the target for this type of efforts

> I honestly don’t see the point in proving to the other side that you can do regular expressions on the user input. ahahaha ✏

love that wording