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 it. 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 --rr _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
