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
