> > 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
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
