XSF Discussion - 2023-04-06

I've only driven as far west as Yellowstone, Portland Oregon is a bit further, 36 hour drive from me

Thanks for the minutes!

As many of you will have noticed, I have been struggling with server-to-server connection configuration details. I've started to write unit tests to check if Openfire's implementation has an expected outcome. That lead to the conclusion that for many combinations of server configurations (on either side of the connection), I was not quite sure what the expected outcome is supposed to be. That lead me to try and map all combinations of possible configuration options, which gave me a six-digit amount of scenarios. To cut back on that, I have simplified the possible configuration options (no longer accounting for scenarios in which, for example, a certificate expiry date is ignorable by configuration, and so on). This gave me 18 distinct configuration option combinations on one server, which is 324 scenarios, if you take into account that every connection involves two servers that can each have different configuration. I then tried to define for each scenario what I think is the expected outcome.

Jumping through all these hoops mentally created a significant amount of levels of indirection for me, so I am looking for help to validate these definitions.

I'd like to see if I can eventually expand on them with more options and/or turn them into unit tests.

Perhaps you have seen/tried https://badxmpp.eu/ ?

I've made the scenario's and outcomes available on Github https://github.com/guusdk/S2SExpectedOutcomeGenerator/wiki/Output along with the not-so-impressive code to generate all the data (in the same Github project).

I have seen badxmpp.eu, and am planning to use that, yes.

For now, I'm interested in figuring out if the 'expected outcomes' as I defined them for each scenario makes sense, from a protocol perspective. I'm not quite sure how to validate them, so I'm asking for help here.

Oh, each possible configuration connecting to each possible configuration? Now I see.

Yes, this is the set that was originally 180.000 items long, that you helped me to reduce, the other day.

Glad I could help

for more bonus points: how can we tell if what I've come up with is sensible?

May I suggest arranging this into a big compatibility matrix?

You may.

Does any of the certificate ≠ missing and encryption ≠ disabled combos make sense?

Does that sentence make sense? :squint:

As in, how would you send a certificate at all without encryption?

And as a corollary(?), requiring valid certificates in Prosody implies that encryption is also required.

some scenarios do not make much sense, but less so than I had imagined. An Initiating Server could still require encryption without providing a certificate itself, I think. (it's probably very unlikely, but for an unidirectional connection that supports Dialback, it's not totally unreasonable)

There might also be reason d'etre for anonymous TLS cyphers here? Unsure - currently unsupported by Openfire, and I'm not sure if we should add that.

In Prosody a certificate is pretty much mandatory for TLS

But it's also easy to start discussing these unlikely scenarios. I'm more interested in the scenarios where a TLS certificate is provided but invalid, leading to a questions like 'should we allow for encryption but not SASL AUTH in this scenario?'

Anonymous TLS exists, I guess, but uh.

My rationale there was that if you want to allow for encryption but not TLS-based authentication, then instead of depending on some configuration that willingly ignores some kind of TLS failure (missing/invalid cert), you could make that desire explicit by making available an ANON cypher, and using Dialback

I'm having trouble reading that list because it is very wide. (Also because I am somewhat sleepy.)

but again - that's not on the top of my priority list.

Yeah, I suck at presenting data

With a sample size of 2 randomly selected lines, I say it seems sensible.

I actually started with a matrix, but turned away from that when it yielded 180.000 results. I'd like to introduce that again, but I'm not sure how to do that in code.

Use the `for` loop Guus

:)

If it were me, I'd probably do it by generating HTML. :)

https://github.com/guusdk/S2SExpectedOutcomeGenerator/issues/1

Github sadly doesn't allow me to assign it to you. :)

Guus: I think it vastly simplifies things if you just don't support dialback, require TLS, and just support all the ways of validating TLS, you miss out on no usecases imho

moparisthebest, you haven't heard about all the Openfire deployments in strange places? :)

moparisthebest: I can't just drop Dialback, as I've got an existing userbase to not alienate.

Not places where TLS doesn't exist

Guus, if you carefully time mention this to me tomorrow, maybe ;) ✏

Guus, if you carefully time of mention this to me tomorrow, maybe ;) ✏

> moparisthebest: I can't just drop Dialback, as I've got an existing userbase to not alienate. This is fair though

Sell dialback support as a ultra premium plugin ;)

Getting paid would be nice, yes.

Zash: I've added the most basic of HTML tables to the output. A screenshot of a rendered version was added to that issue.

No-one will ever state that a competent UI/UX designer was lost in me.

Guus: You said you got about a billon xmpp stickers at home?