Am Mi., 1. Juli 2020 um 20:03 Uhr schrieb Ruslan N. Marchenko <[email protected]>: > > 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.
I think that as soon as you as a client support any kind of channel binding you need to send 'y'. 0440 just helps you to select which one. This means that you as a client just need to make sure that you support at least one that is commonly supported. For TLS1.2 this is probably tls-unique and for TLS1.3 this is tls-exporter. If you can’t make sure that you support that, don’t implement it. (Which is probably something the XEP should be explicit about in case we come to a consensus here.) cheers Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
