XSF Discussion - 2021-05-22

  1. qrpnxz

    https://datatracker.ietf.org/doc/html/rfc6120#section- there's no standard way to know if a feature is required, so idk how this error could ever happen lol

  2. qrpnxz

    well, i guess you could know about a feature enough to recognize it but still not support it

  3. Daniel

    You know it's required if it is the only feature left to negotiate but you haven't been able to bind yet

  4. qrpnxz

    Core 4.7.2 ``` For response stream headers in server-to-server communication, the receiving entity MUST include a 'to' attribute in the response stream header and MUST set its value to the domainpart specified in the 'from' attribute of the initial stream header. ``` However, a from attribute is not always required in the initial stream header, such as before TLS. What do here?

  5. Zash

    Is it not?

  6. Zash

    I thought for s2s both to and from are always required

  7. qrpnxz

    I don't find that it is. After TLS it definitely MUST tho

  8. qrpnxz

    I mean, this paragraph implies that, so I think I'll go and implement it that way, but it don't look like it explicitly say that anywhere.

  9. Zash

    The text about `to` is clearer

  10. Zash

    Historically some wouldn't set either and then you'll have to who they are via Dialback

  11. Zash

    In Prosody we've been gradually tightening up that and making it stricter.

  12. Zash

    It may be upset if you set different to/from before and after TLS.

  13. qrpnxz

    honestly server not including from before tls should be fine. Stream is reset after TLS, initiator sets "from", SASL procedes as normal. Can't even trust the "from" before TLS anyway.

  14. qrpnxz

    perhaps it is the response "to" that should be changed to be made optional before tls

  15. qrpnxz

    and i think in networks you are supposed to be liberal in what you accept as well, so maybe i should not require it in my code

  16. Zash

    The XML way is to be strict and fail early and hard!

  17. qrpnxz

    lol, ok you convince me.

  18. Zash

    If you don't wanna send stuff in the clear then implement direct TLS and hope for ESNI

  19. qrpnxz

    well i gotta decide cause i'm implementing both sides here. I got no problem with sending it, but I'm also gonna be accepting connections.

  20. Zash

    unless gmail.com starts federating again or someone decides to downgrade to ejabberd 2.1.5 I don't think you'll see many streams without both `to` and `from`

  21. moparisthebest

    Funny I was just about to start stripping from= from steam pre TLS in xmpp-proxy

  22. moparisthebest

    Nothing there should make anything fail since an attacker has full control over it

  23. moparisthebest

    Direct TLS sends "to" in sni, but not "from"

  24. qrpnxz

    ok, i'm reconvinced to accept no "from" again xD

  25. qrpnxz

    should be included in direct tls tho

  26. moparisthebest

    I meant pre TLS it's not sent

  27. moparisthebest

    But yes after TLS it's required

  28. arc

    Kev: to be fair, i demand our *German* lion wears loferl socken. As someone who speaks a bit of a few Germanic languages, uses metric grams and celsius, and coaches rugby, this should not surprise anyone 😋

  29. arc