[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Florian Schmaus flo at geekplace.eu
Thu May 7 19:49:49 UTC 2020


On 5/7/20 9:09 PM, Sam Whited wrote:
> 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.

There is absolutely no reason why it should matter (much) if something
like <sasl-channel-bindings/> is a standalone stream feature or a child
element extending 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",

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.


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

Are you sure you did not misunderstand that? There is a difference
between validating known extensions, as in, I know this element by qname
must have an attribute 'foo' and this hasn't one so I error our, and,
erroring out because you encounter an unknown element/attribute. The
latter would absolutely be poison for XMPP.


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

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.


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

If your server only allows authentication if channel binding type X is used.


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

That is what my proposal allows.



>> 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 fail to see how *where* withing <stream:features/> you find the
information causes a difference here.


- 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/20200507/ff06545a/attachment-0001.sig>


More information about the Standards mailing list