[Standards] SASL2 Update incoming

Dave Cridland dave at cridland.net
Fri Aug 25 16:39:14 UTC 2017

On 25 August 2017 at 17:18, Evgeny Khramtsov <xramtsov at gmail.com> wrote:
> Fri, 25 Aug 2017 12:33:54 +0100
> Dave Cridland <dave at cridland.net> wrote:
>> Comments are most welcome!
> While the spec itself is okayish at the first glance, I think it creates
> more problems than it solves. Really, two-factor authentication can be
> done using sequential SASL auth with stream restarts, requirement for
> password change can be done by updating XEP-0077 (using mandatory to
> negotiate feature, as I suggested in the previous discussion of the
> topic), a bind+resume+mam combo can be wrapped into some transation,
> hell, even stream restarts can be avoided by telling "hey, don't
> restart the stream, it's stupid" (because why not, we already bypass
> RFC6120 rules in this proto XEP). I personally really don't know how
> this solves problems of client developers, but for me, as a server
> developers, all this creates additional burden, because I need to
> maintain both SASL protocols anyhow, blowing already over-complicated
> stream management, so this only creates complexity for me. I'm
> absolutely not motivated implementing this just because client
> developers are pussies who failed to write code, and I really don't
> understand why otherwise one needs this new SASL stuff - I don't
> consider stream restarts and sequential stanza processing as a problem.
> Another problem is that with specs like this we move far and far away
> from RFC6120, rendering it more and more useless.


1) On the server side, handling both SASL profiles is actually
surprisingly simple, in my experience. The protocol as documented is
based on actually implementing it in full.

2) Two-factor authentication isn't like two lots of single-factor. I
was surprised too - you'll note that this was how the first version
was modelled, and it's a real pain to make work.

3) I felt it was simpler to ensure that on <success/>, the stream was
authenticated, whereas before it wasn't. Simplifies stream security.

4) I'm not motivated to write this because client developers are
pussies - I don't think they are. I'm motivated to write this because
our general framework for session establishment in XMPP is an
organically grown mess, and starting over seems reasonable if the
gains are high enough.

5) The gains really are high. We gain solid 2FA, significant RTT
reduction, and atomic session establishment. Well, I hope.

But yeah, please do hold me to that goal.


More information about the Standards mailing list