[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Sam Whited sam at samwhited.com
Sun May 10 13:42:58 UTC 2020

On Sun, May 10, 2020, at 08:53, Dave Cridland wrote:
> Not all stream features need negotiation. They're just advertising
> what capabilities are available, not saying you must use them, or
> negotiate them independently.

Ah yes, never mind, I reread 6120 and was writing a response about how
it makes it sound like this isn't allowed, but then remembered that
Roster Versioning and entity caps provide informational features, so
I've got a lot of buggy code that assumes everything is either voluntary-to-
negotiate or mandatory-to-negotiate like 6120 says. Mea culpa, and I've
got some work to do.

> I'd be fine with putting channel bindings alongside mechanisms, just
> not pretending they are mechanisms.

I still don't see why it bothers anyone. We already do this with "-
PLUS", so what is wrong with adding another suffix? So far it's just "I
don't like it" and "I'm not fine with it". I can't really do much to fix
it if I don't know why.

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

What I was trying to say is that I don't think the server can always
support all channel bindings equally, no matter how much we want it to,
not just that it might not want to.

For example, in my tls-exporter I-D [1] I am currently mixing in part of
the SCRAM messages which makes it SCRAM specific. This *cannot* work
with other non-SCRAM mechanisms that support channel binding (such as a
future OAuth mechanism).

Now, since writing that I've decided that the value that we want to mix
in probably doesn't need to include anything SCRAM specific. However, I
don't see anything stopping other future channel bindings from mixing
in data from a specific auth mechanism (eg. to prevent substitution
attacks when credentials are valid for more than one identity). If we
forbid servers from advertising different channel binding types for
different mechanisms, we would not be able to support future mechanisms
that work this way.


[1]: https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/02/

Sam Whited

More information about the Standards mailing list