Hi Daniel, Am Mittwoch, 19. Oktober 2022, 09:23:10 CEST schrieb Daniel Gultsch: > > But that leaves clients not able to implement this type, or any > > channel-binding at all, vulnerable to downgrades of channel-binding types > > and SASL mechanisms. > This specification protects clients that are not able to support > channel binding from being tricked into thinking the server doesn’t > support channel binding either? That doesn’t make sense. No matter if > an attacker strips the channel binding announcement the client still > won’t support channel binding.
No that "being tricked" part refers to a client supporting channel-binding, but none of the types the server announces. An attacker could use this to change the server-advertised channel-bindings to only list a fictional type like "BLURDYBLOOP-CB". That would downgrade the client to not use channel-binding at all, even if both, server and client supported, for example, tls-exporter. A client now has two options: lie to the server and tell it that it does not support channel-binding at all (that's a downgrade now), refrain to connect in that case, or try to use channel-binding nevertheless (but that's roulette, because the client has to guess which channel-binding to use and if the server supports tls-server-end-point, but not tls-exporter and the client uses tls- exporter, the authentication will fail and the client won't have any way to detect if it's because of the channel-binding type it used or because of something else like wrong credentials etc.) See the security considerations of XEP-0440: https://xmpp.org/extensions/ xep-0440.html#security -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
