On 01.07.20 22:01, Ruslan N. Marchenko wrote: > 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? […] If I send n, - that's a downgrade,
I am not sure if this is a downgrade attack (at least a full-blown), or, if it is, if it. Without xep440 the client would have send 'p' in the case you described, with a channel-binding type not supported by the server and hence SASL authentication would fail. We could say xep440 modifies the semantic of the 'n' value of the gs2-cbind-flag from "n" -> client doesn't support channel binding. to "n" -> client doesn't support any channel binding announced/supported by the server. Maybe there are other options, like extending the gs2 header with a flag that explicitly states that the client believes that there are no mutual supported channel-binding types by client and server. But right now, I lean towards explicitly stating in xep440 that the semantic of 'n' is modified in the way I mentioned above. Happy to hear more voices on this. :) - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________