XSF Discussion - 2022-11-26

Openfire is using the stream ID value as the resource value (unless the client supplies a preferred resource value itself). Is there a reason to _not_ decouple the two (and switch to something more random for the default resource value?

Guus, not sure if I understand the question: openfire uses the client provided stream id as resource for clients that don't provide a resource?

ack.

what if the stream id is not a valid resourcepart? :)

that said, I am unable to come up with a reason why this behavior could be problematic, although personally I would just use a random string, and separate the two concerns as they are fundamentally unrelated

there is maybe the small argument of clients that want to use a server assigned resource, but on subsequent logins keep that resource, so that the previous connections, using the same resource, are forcefully terminated by the server

although, that scheme would still work

I am not aware of any guarantees that server generated resources need to provide, but if the client assumes that the server generates a non guessable resource and uses a guessable stream ID, then this would break ✏

Thanks flow. My question was not so much if this behavior (re-using streamID as resource) was problematic, but if there was reason to believe that _stepping away from that_ would be problematic.

from a protocol POV it's certainly not problematic

Thanks. I'm failing to see why this was implemented like this.

git blame it and ask author ;)

but I assume it dates back to some jiver?

gato committed on May 30, 2007: "Initial check in." :)

Wow. The before times. That code is old enough to have learned to propose its own changes.

It's an adolescent now though, so it's judgement calls are to be taken with extreme caution.

But it may be held accountable to its crimes in some jurisdictions.

Guus, not only is it not problematic to change it, the stream id is supposed to be private information, so exposing it to others via the resource string is not a good idea

That said, I'm not aware (for clients) of anything in current use that would cause problems with the stream id being leaked. But definitely change it.

Was it not used in the pre-SASL authentication?

Like, as a nonce

I think so, yes

> Concatenate the Stream ID received from the server with the password. Indeed

Heh, resource binding as part of auth, why did that get broken out into its own roundtrip? https://xmpp.org/extensions/xep-0078.html#example-3

MattJ: thanks - that was my primary reason for wanting to change it. That change has now been merged.

Great :)

Zash, probably because SASL has no concept of a "resource"

but now it's moving back with SASL/bind 2

:)

for non-bidirectional federation, is there a (good) reason to allow/facilitate one-way connections? Openfire, in certain circumstances, will now prevent an outbound connection to be established when it determines that the inbound connection's auth will fail. I wonder if that's right.

How does it determine "the inbound auth will fail"?

it presents a certificate that we won't validate, and dialback is not available.

(it might still accept our certificate)

You don't know that you'll see the same certificate if you connect back

In fact if the cert is not trusted, that could be even more likely (since it may not be from the real server for that domain)

I guess that was one (unintentional) benefit of Dialback, ensuring bidirectional connectivity.

But mTLS + BIDI is nice

DM-TLS?