0) Servers MUST implement tls-server-end-point and enable/advertise it. Clients SHOULD implement tls-server-end-point and use it if no other (stronger) channel-binding method is supported by both sides.
I think that would be horrible advice these days -- the tls-server-end-point gives a false sense of security and is known sub-optimal for years. It would be similar to urge people to MUST implement 3DES or RC4 for TLS. There is no fatal attack for those either, but the collective wisdom is "don't use them".
I suggest to mandate tls-exporter from RFC 9266. I believe any deployment not being able to support this is better off not supporting channel bindings at all, because doing so just adds complexity and attack surface and end-user confusion ("oh nice I have a channel binding!") for little gain.
I really object! tls-server-end-point is vastly better than no channel-binding at all! If you need a real world example: It would have prevented the jabber.ru attack. I get that its not the best channel-binding we have at hand here, but that MUST in rule 0 isn't a "please don't do better", but rather a "please don't do worse". Its a *minimal* requirement. And like others already said, there are deployments that can't do exporter. Preventing them from being able to do channel-binding at all would be very bad. And yes, using tls-exporter as "minimal" requirement instead would do exactly that: prevent channel-binding at all. See, you need a channel-binding that can be implemented and deployed in *absolutely* all scenarios, for my list of rules to work and block the attack in rule 5. Tls-exporter just doesn't meet that requirement. Even worse: just doing an s/tls-server-endpoint/tls-exporter in these rules will not only render rule 5 completely useless, but make it harmful: it would block all deployments only being able to do tls-server-end-point. Those deployments would need to turn off channel-binding completely to allow clients following those rules to authenticate at all. So I ask you: do you want to block all deployments using tls-server-end-point from using channel-binding at all, substantially lowering their security, just because having tls-exporter named in a XEP feels better than tls-server-end- point? We can always name tls-exporter explicitly in the XEP, though. Maybe something like: Servers and clients SHOULD implement a stronger channel- binding like tls-exporter, if at all possible. -tmolitor