[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Sam Whited sam at samwhited.com
Thu May 7 19:09:35 UTC 2020


On Thu, May 7, 2020, at 13:11, Florian Schmaus wrote:
> I did, at first. It is totally irrelevant if it is an extra stream
> feature or not. This just seemed a little bit more esthetic.

I disagree, it's very relevant. We can discuss both, but how things work
and are implemented may be entirely different if this is a stream
feature that may be negotiated before auth vs. an informational element
on an existing stream feature.

Let's stick to discussing the informational feature on <mechanisms> for
now so that we avoid this confusion and we can go back and discuss the
separate stream feature later if necessary.

> > Can we modify the mechanisms feature?
>
> Yes, we can. Extensibility is one if the key concepts of XMPP.

I apologize if this was unclear, I meant "can we do so without a version
bump or without breaking existing implementations". I am reasonably sure
the answer is "no", but am open to being convinced otherwise. The
original mechanisms feature did not provide a way to be extensible
except by defining new SASL mechanisms, and I think forcing new elements
into it will be a breaking change for the reasons I mentioned in my
previous email. If we want to allow arbitrary child elements we may need
a new spec, like SASL2 (however I need some form of negotiation right
now with legacy SASL, so maybe having a discussion about how SASL2 can
do this better is orthogonal). To focus on a specific example:

> If you do a strict schema validation that errors out as soon as it
> finds an unknown element or attributed (prefixed or not), then you
> have already lost in XMPP.

I think I've tried to modify existing extensions in the past and been
told that some servers were doing it this way in the wild. They may not
be doing it for eg. IQs, which can take arbitrary payloads and have a
well defined error condition if you don't support the payload (I assume?
Maybe someone who does this can weigh in?), but I assume stream features
would be something you can do strict schema validation for and maybe
even would want to from a security perspective. Again though, I was just
saying this because someone complained about one of my specs modifying
something in the past that would break their schema, I may be
misremembering so maybe someone who maintains software that actually
uses schemas can chime in.

Are there other widely implemented XEPs that modify the possible
payloads of existing core RFC features (or even unrelated XEPs)? Some
examples would be good, I can't think of any off the top of my head.


> Even though it means an enforcing server would *potentially* block
> clients unaware of this extension. But if you server- side enforce it,
> then you kinda accept that.

I didn't understand this, sorry. If you server-side enforce what? I was
trying to find a solution that allowed complete backwards compatibility:
clients and servers can keep doing exactly what they're doing today, and
continue to work with clients or servers that support the new thing.

Servers potentially blocking clients is what we're trying to determine:
will they or not. If they do (and don't have the option of backwards
compatibility), that seems like a non-starter.


> What I said in my previous mail still applies. You either want
> always that hypothetical new channel binding type or, you want it
> and eventually others for backwards compatibility. The initiating
> entity, the client in c2s, has an incentive to select what he finds
> most secure.

This is one of the differences with a stream feature vs. an addition to
an existing stream feature. I was arguing against this if the CB
negotiation was a separate stream feature, however my objections to it
are irrelevant if we're talking about an addition to the SASL feature,
so let's also ignore this for now and we can come back to it if we
discuss the separate stream feature case later.

—Sam

-- 
Sam Whited


More information about the Standards mailing list