jdev - 2021-01-13


  1. Sam Whited

    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.

  2. Zash

    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.

  3. Sam Whited

    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?

  4. Zash

    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

  5. Sam Whited

    oh, gotcha

  6. Sam Whited

    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

  7. Sam Whited

    I hate having a magical special case in there though

  8. Zash

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

  9. Zash

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

  10. Sam Whited

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

  11. Zash

    I don't remember

  12. Zash

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

  13. Sam Whited

    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

  14. Zash

    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.

  15. Zash

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

  16. Sam Whited

    I don't understand the distinction

  17. Sam Whited

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

  18. Zash

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

  19. Zash

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

  20. Sam Whited

    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

  21. Sam Whited

    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

  22. Zash

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

  23. flow

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

  24. Zash

    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.

  25. Zash

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

  26. flow

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

  27. Zash

    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

  28. Zash

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

  29. Zash

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

  30. moparisthebest

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

  31. flow

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

  32. Zash

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

  33. moparisthebest

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

  34. moparisthebest

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

  35. Zash

    Or drop certificates and use raw public keys!

  36. Zash

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

  37. moparisthebest

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

  38. Zash

    Raw public keys? Yeah.

  39. moparisthebest

    I assume it was dropped with TLS 1.3

  40. Zash

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

  41. Zash

    Only the web can have nice things.

  42. Sam Whited

    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)

  43. Sam Whited

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

  44. Zash

    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.

  45. Zash

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