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 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? > 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). 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. 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. > 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."? —Sam -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
