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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
