[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Florian Schmaus flo at geekplace.eu
Fri May 8 07:20:48 UTC 2020

On 5/8/20 12:10 AM, Sam Whited wrote:
> 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 adds a previously unspecified <optional/> to <session/>, which is
exactly what <sasl-channel-bindings/> is to <mechanisms/>. That
<optional/> is not under a different namespace largely irrelevant.
Suddenly there is a now element unknown to implementations unaware of it.

> 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?

It does not matter if it is an widely implemented XEP or not. The fact
alone, that we extend elements by further elements/attributes later on
without a namespace bump, means that your validation mechanism should
not choke on unknown elements/attributes.

But sure, I will do some digging for you, here you go:


>> 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).
We do not allow input, we ignore it.

> 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.

That argument is flawed. If we ever where to hash <mechanisms/>, then we
would do what we always do when it comes to hashing: clearly specify
which data is hashed and in which order. As otherwise, you would need to
resort to XML normalization, which you usually do not want to do, due
its complexity. And explicitly specifying what gets normalized comes
with the advantage that you can later extend the elements by additional
elements/attributes, without breaking the hashing scheme. An example of
this is the hashing algorithm specified by xep115/390.

> 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.

And again, if you you do a strict schema validation that errors out as
soon as it finds an unknown element or attribute (prefixed or not), then
you have not understand how extending XMPP works.

Schema validation in XMPP is about validating *known* elements and
enforce the rules. Like, if there is a {foo}bar element, then it must
have a boolean attribute named 'required'. Or, if there is a {foo}baz
element, then it must have a at least three {foo}option child elements.

If entities where to enforce such a strict schema validation as you
argue with, then we would take away an easy way to upgrade the protocol
without (namespace) version bumps for no gain.

>> 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."?

No, I said,
"Even though it means an enforcing server would
*potentially* block clients unaware of this extension."

The "potentially block" may be a little bit confusing, so let us play a
game (CB is channel binding in the following):

Non-CB enforcing server + No <sasl-channel-binding/>
→ Same situation as when <sasl-channel-binding/> did not exist, clients
  may select an unsupported CB and chaos ensues. What then? Can you
  (re)try SASL directly again? Will the client disconnect and try again?

Non-CB enforcing server + <sasl-channel-binding/>
→ The client knows which CBs are supported, *no* chaos ensues.

CB enforcing server + No <sasl-channel-binding/>
→ Same as the first point. The list of SASL mechanisms offered by the
  server is potentially shorter, but the client still has to be lucky to
  select a supported CB type.

CB enforcing server + <sasl-channel-binding/>
→ Client knows which channel binding type it can use. Basically the same
  as the second point. But clients unaware of the extension may fail,
  because they where unlucky and selected an unsupported CB type, wha
  follows is chaos akin to the first point.
  *That is what I meant in the quoted statement above.*

Eventually, you do not lose anything with <sasl-channel-binding/> but
only win additional information that you can use to increase you chance
of a successful or more secure authentication. That is why it falls into
the category of "additional information that is nice to have but not
(strictly) required" extensions, that do not require a namespace bump.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200508/3b49d170/attachment.sig>

More information about the Standards mailing list