[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Sam Whited sam at samwhited.com
Thu May 7 22:10:23 UTC 2020

On Thu, May 7, 2020, at 15:49, Florian Schmaus wrote:
> I am sure we do not need an version bump for this. The information of
> <sasl-channel-bindings/> falls into the category "additional
> information that is nice to have but not (strictly) required". We
> extend existing elements by new elements or attributes without a
> namespace bump all the time.
> https://tools.ietf.org/html/draft-cridland-xmpp-session-01 is a nice
> example of this.

I read that through a few times, but I don't really understand how it
applies to the current discussion. It does not appear to arbitrarily
modify another extensions namespace, it just creates a new (well, an
"old" but it's new again in 6120) stream feature, a defined point of
extensibility that is very common. Can you please elaborate, or, better
yet, find an existing widely implemented XEP that adds payloads to
another XEP or RFCs namespace?

> Are you sure you did not misunderstand that?

Yup, like I said in my previous email it's quite possible that I'm
misremembering and someone who actually works on a product that does
this will need to chime in.

> Why would this be desirable from a security perspective? In the end,
> your implementation will simply ignore unknown elements/attributes.
> There is no gain in security if you error out before.

In general it's best practice to not allow arbitrary input in security
critical contexts (like auth). Our client MAY just ignore it, or we may
be using that message later, eg. hashing it into some other data so that
the hash will become invalid if the auth mechanisms change, and we don't
want arbitrary other text in there breaking our hash. To be clear, I
don't know of anything doing this in the wild, and I'm not suggesting
that adding things will definitely be a security vulnerability (in fact,
it almost certainly won't be) but we'd want to be very careful before
adding more stuff to <auth>. All that being said, that really wasn't the
point of the paragraph you were replying to and it's not a hill I'd want
to die on. I just mention it as one reason being stricter about the
namespaces during this step might be something people are doing.

> That [backwards compatibility] is what my proposal allows.

Didn't you just say it was possible that your proposal would break
existing clients or servers that don't support the new extension? Maybe
I misunderstood, but I don't see how that's compatible with "Even though
it means an enforcing server would *potentially* block clients unaware
of this extension."?


Sam Whited

More information about the Standards mailing list