[Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Ruslan N. Marchenko me at ruff.mobi
Wed Jul 1 20:01:12 UTC 2020

Am Sonntag, den 14.06.2020, 13:05 +0000 schrieb XEP Editor Pipeline:
> Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has
> been released.
> Abstract:
> This specification allows servers to annouce their supported SASL
> channel-binding types to clients.
This describes advertisement semantic however it does not solve the
main problem which channel binding mechanism is trying to solve and
which is more or less broken currently - integrity and confidentiality.

I've tried to implement that and immediatelly stumbled upon gs2_flags -
how to handle _no-match_ case? As per [5802] client needs to send y
when it thinks server does not support binding, but client does support

What to do when I can bind tls-server-end-point and server can bind
tls-unique? Or opposite, whatever. If I send n, - that's a downgrade,
if I send y, - that's a clear failure case (server will abort as it
advertised -PLUS). So the only outcome is not to use SCRAM whatsoever
but that's again a downgrade.

So in a nutshell this opens a way for MitM to disable channel bindings.

Am I missing something here?

[5802] https://tools.ietf.org/html/rfc5802#section-6


More information about the Standards mailing list