jdev - 2021-01-13

While testing my server implementation I just realized that bind is broken because I always match the feature being selected by the namespace but bind does its magic IQ stuff. Does everyone else just special case this? I really have no good idea how to handle this in a sane/general way.

Prosody used to special-case pre-binding IQs, explicitly excempting by namespace and stuff. Now it treats them as stream elements until after resource binding.

What does it mean to treat them as stream elements? Does that mean in theory the bind IQ could be sent at any time during the negotiation process?

And then there's a bit of special dispatch for {default namespace}iq, but they're not iq stanzas as far as routing is considered

oh, gotcha

Yah, I don't start IQ handling at all until after the session is negotiated so they're not actually treated as IQs, but I guess I'll have to special case "if you get <iq/> pass that to the bind handler" instead of just relying on namespace

I hate having a magical special case in there though

Yeah, I wasn't a fan of having resource binding or IBR special-cased so early in routing.

Also why I'd like to move away from such iq-looking things.

Oh is IBR special too? I didn't remember that, I'll have to go re-read that one

I don't remember

Hm, could be that it was only binding that was special, since it happens after authentication

hmmm, well, I don't want to deal with that one right now (or possibly ever) so I may just say "if you get an IQ, pass it to the bind handler" to start and ignore IBR until someone complains

So the change in Prosody was in when <{jabber:client}iq> becomes a stanza, as opposed to a stream element (.... nonza). Before it was at authentication, now it's at resource binding.

This makes sense to me since you need a resource for routing.

I don't understand the distinction

Or how it could be at authentication since it's always used for resource binding?

There's a period in the life of a session between authentication suceeding and resource binding

What happens if you try to send a message before resource binding?

Oh, I don't actually have handlers for messages or anything at that point so it would just think there was no such feature and say that "jabber:client message isn't an advertised stream feature" or something

But that makes sense if you're already handling messages and IQs and what not, which I guess technically I should be since I think in theory you could send them to the server before negotiation is complete

Does anyone have a client supporting XEP-0440 and `tls-server-end-point` ?

Zash, if you provide a server implementation then I would be very tempted to provide the client side implementation

flow: I've got an initial WIP where you need to supply the cert hash yourself, wondering if I should publish as-is or wait for library support for getting the hash to use to get it.

Oh dear, dual RSA/EC cert setups are going to cause pain.

Zash, with your current approach, where teh cert hash is externally supplied, I assume?

With the next step of the WIP where it tries to hash the configured certificate. Which is already a blocker because it doesn't know what hash function the cert is signed with, and you're supposed to use the same if it's better than sha-256

flow: Not specifically, more in general. Prosody doesn't support it anyways.

And in the TLS offloading proxy setup where it makes sense to do with a configured cert hash, certificate rollovers will be fun.

cert hash or key hash? basically things should only use key hash ever imho

Zash, yep, in TLS offloading setups this may be more pain than gain

moparisthebest, I'd actually like to have (maybe even write) a channel binding thing that says "use the SPKI as-is"

oh, channel binding, that's probably fine, I should read first

yea that'd be neat, match up with DANE well (and maybe we can do HPKP for XMPP one day...)

Or drop certificates and use raw public keys!

Of course that's never going to happen. Can't actually have nice things.

I swear there used to be a TLS mode that did that

Raw public keys? Yeah.

I assume it was dropped with TLS 1.3

https://tools.ietf.org/html/rfc7250

Only the web can have nice things.

Maybe if you get an IQ instead of the expected thing to start a stream feature it should check the payload and use its namespace to determine which stream feature to select. That seems more general purpose. If the stream feature isn't bind and you somehow get a client sending <iq><sasl> or something, the thing that parses it will just not support the IQ and will fail, so whomever wrote the stream feature implementation could decide whether to support IQs or not (probably just bind, but I dunno, maybe someone wants some other legacy feature that uses IQs at some point)

That seems vaguely more general purpose than just special casing bind, even though I doubt it's very useful.

Event based architecture, dispatch on top level {xmlns}name, hook {jabber:client}iq and further dispatch on the iq payload {xmlns}name. Not exactly how it works in Prosody but sorta.

And something something session state in (unauthed → unbound → ready) or somesuch