[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Dave Cridland dave at cridland.net
Sun May 10 12:53:14 UTC 2020

On Wed, 6 May 2020 at 23:20, Sam Whited <sam at samwhited.com> wrote:

> On Wed, May 6, 2020, at 18:03, Dave Cridland wrote:
> > The TL;DR is "horrible syntax, but really useful idea". … So, I would
> > love to see this problem tackled properly, but without a syntax that
> > involves me wanting to stab myself in the eyes with a fork.
> Daniel said something similar but I don't understand what either of you
> don't like about it? It's such a small thing it can hardly even be
> described as syntax since you'd likely hard code mechanism names that
> you implement.
> > I wonder if just listing channel bindings, and mandating that channel
> > bindings are offered for all mechanisms that support them equally,
> > might be better.
> How would you list them? If it's another stream feature, it would have
> to be special cased that it's not something to be negotiated, but

Not all stream features need negotiation. They're just advertising what
capabilities are available, not saying you must use them, or negotiate them

> somehow has to have its state be saved and understandable from whatever
> parses the <mechanisms/> feature. This would break a lot of assumptions
> I made when implementing stream negotiation that I think were reasonable
> assumptions from reading 6120. If it is negotiated, see my response to
> Daniel. I just don't really know what that would mean and it adds a lot
> of complexity.
I'd be fine with putting channel bindings alongside mechanisms, just not
pretending they are mechanisms.

But equally, I'd be fine with a seperate stream feature, too.

> Also, as I said in my other email: I don't think you can mandate that
> channel bindings are offered equally for all mechanisms. Right now we
> just have SCRAM, but in the future we may also have OAuth or something
> that uses channel binding. It may not have all the same channel binding
> methods defined for it. Of course, this risk may be minimal enough that
> we don't care.
Currently that is not so - channel bindings exist at the GS2 layer, and are
defined there. SCRAM doesn't define what channel bindings are allowed, and
the part of its syntax that defines the declaration of what channel binding
is used is the gs2-header. What it does define is an MTI that (as you point
out) is unsustainable.

It *is* possible that a server might not support all channel bindings
equally, but I think that server would be broken.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200510/d354c096/attachment.html>

More information about the Standards mailing list