XSF Discussion - 2021-05-22

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

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

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

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?

Is it not?

I thought for s2s both to and from are always required

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

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.

The text about `to` is clearer

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

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

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

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.

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

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

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

lol, ok you convince me.

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

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.

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`

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

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

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

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

should be included in direct tls tho

I meant pre TLS it's not sent

But yes after TLS it's required

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 😋

Liason