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

Daniel Gultsch daniel at gultsch.de
Thu Jul 16 09:46:13 UTC 2020

Am Mi., 1. Juli 2020 um 20:03 Uhr schrieb Ruslan N. Marchenko <me at ruff.mobi>:
> 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.)


More information about the Standards mailing list