XSF Discussion - 2023-06-15

  1. Guus

    In a server-to-server context where both have dialback enabled, both require encryption, if the receiving server sends a valid certificate and the initiating server responds with an invalid certificate, should the connection be allowed to go ahead encrypted via TLS but authenticated via dialback?

  2. MattJ

    That's up to you

  3. MattJ

    If you're willing to use dialback for authentication, and it succeeds, why would you do at different?

  4. MattJ

    If you're willing to use dialback for authentication, and it succeeds, why would you do anything different?

  5. Guus

    https://datatracker.ietf.org/doc/html/rfc6120#section-13.7.2 specifies: > If any of those validation attempts fail, the validating entity MUST unilaterally terminate the session.

  6. Guus

    It is likely OK for the initiating server to 'start over', this time not providing the invalid TLS certificate, taking SASL EXTERNAL off the table - but I was wondering if it would be permissible to allow Dialback on a pre-existing connection on which SASL EXTERNAL has already failed because of the invalid certificate.

  7. lovetox

    Guus, does openfire implement occupant-id (https://xmpp.org/extensions/xep-0421.html) ?

  8. MattJ

    Guus, that section is about how to authenticate a connection using TLS

  9. MattJ

    If you're happy to not authenticate using TLS, you're already not following the RFC

  10. MattJ

    or depending on your perspective, you're following it but you just don't consider invalid certificates as invalid :)

  11. MattJ

    (but not sufficient to authenticate, either)

  12. Guus

    lovetox: Openfire does currently not support XEP-0421

  13. Zash

    Out with Dialback! In with SASL EXTRRNAL and BIDI!

  14. Guus

    MattJ: thanks. I'm wondering if there is some (maybe implicit) security issue with using a TLS session in which a 'client' cert has been provided, but is not being used.

  15. MattJ

    No more than there is an implicit security issue with using unencrypted connections

  16. Guus

    MattJ: the connection would still be encrypted though?

  17. Guus

    it's just not _authenticated_ through TLS, right?

  18. MattJ


  19. MattJ

    I'm saying that's better than e.g. dialback over unencrypted connections, which would be the alternative

  20. Guus

    I'm not sure if that's the only alternative. There's something to be said for a 'kill the connection, let the initiator try again without providing a client cert'. Thus forcing encryption, using dialback for authentication.

  21. MattJ

    I'm not sure what there is to be said for that flow, actually

  22. Guus

    You'd not have a connection on which a TLS certificate was provided that you have judged to be 'insufficient for auth'.

  23. Guus

    Which is arguably more in line with section 13.7.2.

  24. MattJ

    I'm pretty sure if you implement it that way, nobody will ever be able to connect to you

  25. MattJ

    Because servers just always provide certificates

  26. Guus

    given that no server implements that 'try again without client cert' routine?

  27. Guus

    That is probably a very valid point.

  28. Guus

    (I could start a trend though ;) )

  29. MattJ

    How would they even know, if you just terminate the connection?

  30. Guus

    They'd not, I guess. Blindly retrying with TLS but without a certificate, and eventually without TLS and only dialback?

  31. Guus

    it's messy and verbose.

  32. Guus

    (and should all be very much based on configuration that defines acceptability of having dialback and/or non-encrypted connections)

  33. Zash

    This sounds messy

  34. Guus

    (Thanks for the ticket, lovetox - sadly, I can't make promises on the turn-around time)

  35. Guus

    That's what I was leading with, Zash :)

  36. Guus

    but connectivity > messy ?

  37. lovetox

    Guus, no worries, we play the long game with xmpp, but if there is no issue, chances are even lower of someone doing something :)

  38. Guus

    absolutely. Also, we have clients/customers that occasionally go through our issue tracker and ask us to 'fix that'. So having a ticket is a good start.

  39. Guus

    (paid work tends to get done quicker than unpaid work)

  40. lovetox

    does anyone know whats the usage state of https://xmpp.org/extensions/xep-0258.html Is this something worth keeping/implementing in clients like Gajim? We currently support it, but i tend to remove it. Its hard to test, because not supported by some servers, and its hard to find users who want to use this in a serious manner and not just to play around.

  41. Zash

    lovetox: The one who need it can definitely pay :)

  42. Kev

    We use 258 extensively, but I don't think removing it from a typical consumer client is at all daft - it's pretty niche.

  43. Guus

    I wonder to what extend developers make use of typical consumer clients that happen to support it, to test their 258 implementions - but hey, you'll probably hear them complain soon enough :)

  44. lovetox

    its tempting because its pretty easy to implement, you simply display the labels you get on the message, and let the user attach one when sending

  45. lovetox

    but yeah, maintaining this without real use feedback is pretty mäh

  46. lovetox

    im sure someone complains if i remove it :/

  47. MattJ


  48. Zash

    Every change breaks _someones_ workflow!

  49. Guus

    ... but somehow it feels like people are explicitly targeting mine. ;)

  50. emus


  51. edhelas

    Goodies <3

  52. emus

    Yes, not just for that, but also for the upcoming sprint: https://wiki.xmpp.org/web/Sprints/2023-06_Elbe-Sprint_Hamburg Please sign up uf you are interested to join

  53. Fishbowler

    I worked on a project for a customer a couple of years back where we added 258 support to Converse. They refused to permit it to be contributed to the project, instead preferring a fork. I'd wager that many orgs that like 258 also like private forks :(

  54. lovetox

    What the opinion on add reactions to your own messages

  55. lovetox

    The XEP says nothing on this

  56. lovetox

    sounds stupid to me, but who knows maybe someone has a use for this

  57. Zash

    I don't see why not

  58. lovetox

    because its stupid :D

  59. Zash

    Has that ever stopped users from doing something? :P

  60. lovetox

    the reaction XEP doesnt even limit the amount of Reactions you can give, if self reactions are allowed, i could give my own messages 100 thumbsup

  61. Menel

    So lets do sensible clients

  62. lovetox

    true, one can simply ignore that in the client

  63. lovetox

    though not allowing self reactions, would enable us to use the stanza-id as reference, which would be nicer

  64. cal0pteryx

    looking at our gitlab I see many people reacting to their own issues :D

  65. cal0pteryx

    ..to no avail :)

  66. singpolyma

    Reactions on own message are normal, especially for voting situations

  67. Guus

    I frequently use reactions on my own messages in other IM solutions

  68. lovetox

    ok, why not ..

  69. Zash

    Probably same with replies ;)