TL;DR IMO we should be stricter about the sync/async separation and not add more IQs before the session is established.
I'd like to second this, but not from a security perspective but from a general dev / separation of concerns prospective (which I suppose is also a security perspective). An XMPP session in general can be divided up into the synchronous session establishment and the async session that you establish. IQs are meant to be used in the async part and their semantics only make sense in an async context (eg. they have IDs used to track responses, but this is not needed if the response will always be the next thing received). With the exception of the resource binding IQ, this distinction holds and I normally write my code to assume this distinction, then have to find a way to piggy back IQ semantics (which I had written tied into async code requiring a session) onto the binding IQ. This normally means duplicate logic and more places in the code for bugs when the parts I had to rewrite (mirroring an ID and the like) aren't even necessary. —Sam On Tue, Nov 3, 2020, at 16:51, Dave Cridland wrote: > My main concern here is the addition of a further IQ during > unauthenticated state. In the case of every server I've worked with, > the IBR (and '78 auth, if supported) is hard-coded into the server. > This generally feels like a security nightmare lurking. > > I would rather move in the other direction, and place the entirety of > registration inside non-stanza TLEs or (possibly) opting for a registration- > only authentication before exchanging stanzas. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
