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