XSF Discussion - 2021-09-01

  1. MattJ

    emus, I can add it to the agenda. What we need is someone to volunteer to be the organization admin (and someone else as a fallback). They will need to submit the application and manage everything if we get accepted. Perhaps you could write to members@ seeking volunteers?

  2. huge

    How can I withdraw the message?

  3. MattJ

    huge, https://xmpp.org/extensions/xep-0424.html

  4. huge

    thank you, MattJ

  5. emus

    MattJ: That is good. If someone offers to support with advises who already did it im happy to volunteer

  6. dwd

    moparisthebest, How do you feel about asking the Editor to issue a Call For Experience on XEP-0368 and get it to Final?

  7. moparisthebest

    I did that before and there were comments I said I'd address, I remember that much and them promptly forgetting to do it...

  8. moparisthebest

    I did that before and there were comments I said I'd address, I remember that much and then promptly forgetting to do it...

  9. jonas’

    indeed, we did have a CFE on 2020-02-11

  10. jonas’

    the document hasn't been updated since 2019, sooo....

  11. moparisthebest

    see? my memory is only half bad :P

  12. dwd

    Yes, mixing definition was the only thing. But equally, ejabberd does XEP-0368 as well as Openfire, so we've the server-side fully covered.

  13. dwd

    I can give you some text, on list (or in a PR), which i think covers the mixing question if you like.

  14. moparisthebest

    was that the only update? sure I'm fine with either of those

  15. dwd

    Specifically, I'm thinking "MAY treat them equally (ie, mix), but MAY prefer direct TLS". I don't want to suggest that people should prefer StartTLS, I don't think that's sane.

  16. moparisthebest

    it does already have "However, clients MAY choose to prefer one type of connection over the other." but yea it probably makes sense to tweak that as you said

  17. moparisthebest

    Conversations and xmpp-proxy implements mixing, unsure what other implementations do if any

  18. dwd

    Metre mixe{s|d}, as does Openfire I think. Not sure what ejabberd does, but Holger knows all.

  19. Holger

    ejabberd mixes.

  20. Holger

    Someone (Sam?) was ranting against that behavior the other day, because "why not just always prefer direct TLS".

  21. dwd

    But I know that there's plenty of clients out there that hit all the _xmpps-client records to exhaustion before touching _xmpp-client, and that seems OK. The reverse seems... odd. I'd rather be in a position in five years to deprecate StartTLS.

  22. moparisthebest

    fwiw future not-yet-written thing using SRV2 will deprecate XEP-0368, XEP-0156, and how the RFC uses SRV

  23. Holger

    I guess the question is whether there might be any interop implication with one or the other behavior.

  24. moparisthebest

    though obviously none will go away... forever?

  25. jonas’

    moparisthebest, are you saying it needs an RFC?

  26. moparisthebest


  27. Holger

    The 6120 successor should just hard-code direct TLS on port 443, end of story :-)

  28. moparisthebest

    server can't count on mixing or not regardless, because from it's POV it can't tell if a client doesn't implement mixing or is on a network with blocked connectivity

  29. Holger


  30. moparisthebest

    Holger, or Quic on UDP port 443 yea :)

  31. Holger

    Indeed, I'm just old-school.

  32. moparisthebest

    personally I'd like to have XEP-0368 fallback to hard-coded 443 if no records are returned, but I assume that'd be so controversial I didn't want to bring it up

  33. Zash


  34. moparisthebest

    if you don't like this don't look at what xmpp-proxy does ;)

  35. dwd

    The ALPN stuff is just a bit too new fangled for me.

  36. Holger

    I'd like to see a hard-coded fallback to xmpp.$domain:443 to cope with the case where SRV lookups fail 😂

  37. moparisthebest

    one other text I'd like to change/clarify before final is: > If the _xmpps-client (or _xmpps-server) target is set to . (dot), this indicates as per RFC 2782 [3] that the service is not provided for the given domain. In this context, this means that Direct TLS is not supported. In this case, the initiating party SHOULD look up _xmpp-client (or _xmpp-server) records. The initiating party MUST NOT perform A/AAAA fallback as per RFC 6120 [1] (since the service provider has already indicated that the SRV protocol is supported).

  38. moparisthebest

    this isn't clear that a response like this should be utterly ignored if not signed with DNSSEC (so 99% of the time in practice)

  39. Holger

    Right now, $domain:5222 needs to be accessible to cope with those.

  40. dwd

    moparisthebest, I'd note that in Security Considerations, alongside that any records may be spoofed without DNSSEC.

  41. moparisthebest

    or just take it out entirely since there is no fallback in 368 at all either

  42. Zash yells "Fallbacks ports were a mistake!"

  43. dwd

    They were unless you need them.

  44. moparisthebest

    *tor users yell "but we still don't have a sane way to look up srv records"*

  45. Holger

    What's the motivation of the 'MUST NOT perform A' part?

  46. Holger

    Just to avoid an unnecessary lookup?

  47. moparisthebest

    dwd, security considerations do note that all DNS responses are subject to modification/spoofing in abscense of DNSSEC, but it's not quite explicit enough for me

  48. moparisthebest

    Holger, that's just from the SRV spec, to let an admin signal the service isn't supported and you shouldn't even try

  49. moparisthebest

    but again, should be ignored almost all the time :/

  50. dwd

    moparisthebest, Yeah, I'd note that '.' is particularly vulnerable and leave it at thta.

  51. Holger

    I see no interop problem with trying.

  52. Holger

    So personally I'd omit that.

  53. Holger

    The SRV spec is wrong :-)

  54. moparisthebest

    I think it's fine in a world where DNS is trustworthy, unfortunately...

  55. Holger

    In my book, MUST clauses exist to avoid interop problems.

  56. Holger

    Therefore, a clause that says 'MUST avoid $x' just because $x seems unnecessary to the spec author confuses me while reading a spec.

  57. Holger

    But whatever.

  58. moparisthebest

    You are right imho

  59. moparisthebest

    I look at this from the perspective of the user, they want to connect, that means you should do everything possible to connect, that means all the methods, all the fallbacks etc etc

  60. moparisthebest

    oh, and now I remember another change, though thinking on it maybe it'd be more appropriate in another "best practices" type xep

  61. moparisthebest

    but roughly, when to abort connecting vs when to move to next srv record / connection method (tl;dr almost never abort connecting)