[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Sam Whited sam at samwhited.com
Sun May 10 21:20:08 UTC 2020

On Sun, May 10, 2020, at 10:34, Florian Schmaus wrote:
> "Look, they did the same bad thing here, then it must be OK if I do
> the same", is no argument.

Why is it bad? That is what I'm asking. You're starting from the point
that "-PLUS" or "-tls-unique" are bad somehow, I am arguing that
they're not. So far no one has told me what they think is actually
wrong with it (with the exception that you mentioned that you think the
list could be long, which I'll address in just a moment), they've just
proposed alternative solutions with no indication of what is wrong with
the one I proposed.

> It (1) unnecessarily bloats the SASL mechanism space with (2)
> unregistered mechanisms while (3) additionally adding a lot of
> redundant information.

Why is this a problem? At most it's 4 or 5 extra mechanisms. It is never
going to be enough data to cause a problem as far as I can tell.

> 2: All those mechanisms do not, and very likely will never, appear in
>    the IANA SASL mechanism registry.

Yes, the spec specifically says that they shouldn't. I also don't see a
problem with this, they are specific to this spec and XMPP and don't
need to be listed everywhere. Not listing them also doesn't create an
incompatibility with anything else.

> 3: Since you can assume that if a server (or implementation in
>    general) supports a channel binding type, it is supported for all
>    SASL mechanisms. Your suggestion repeats that same information, the
>    supported channel binding types, multiple times.

As I explained in my previous email, we can't assume that.

> Even if there is a channel binding type that is specific to a SASL
> mechanism, then the server announcing … would be sufficient for the
> client to now what do to. Even if 'tls- exporter' is SCRAM specific,
> because its specification then surely would declare the supported SASL
> mechanisms.

Ah yah, you're right about this, it just moves the burden of knowing
what mechanisms can use what channel binding types from the server to
the client. I think this is fine.

> I don't see why anyone would ever want design a SASL mechanism
> specific channel binding type. I am happy to learn about potential
> reasons, of course.

I briefly mentioned one reason why you might want to in the paragraph
you're replying to. However, I'll try and come up with a more concrete
example (though with the disclaimer that this will necessarily be
somewhat contrived):

Imagine that we're on a corporate network that MITMs all TLS connections
with one of those proxies that requires that you install a root cert on
your machine. Traditional channel binding like tls-unique is designed to
cause auth to fail in a case like this because the client and the server
see a different TLS connection. This is good! However, we may still want
to use XMPP on this server so we design a new SASL mechanism that
negotiates its own security layer inside of the TLS layer (something
SASL mechanisms are allowed to do). We want this new mechanism to
support channel binding, so we use the tls-unique data from the SASL
negotiated security layer. However, we also want auth to fail if the
connection to our corporate firewall has been reset and is now pointing
at a malicious actors machine on the same network, so we mix in the
original tls-unique data as well. This is now a new channel binding type
that is specific to our auth mechanism. Like I said, I know this example
is incredibly contrived, but we can't predict what sort of auth
mechanisms we'll have in the future, and this doesn't seem so incredibly
unlikely that we shouldn't consider it.


Sam Whited

More information about the Standards mailing list