On Tue, Feb 4, 2025 at 4:02 PM Stephen Paul Weber <singpol...@singpolyma.net> wrote:
> >4. Do you have any security concerns related to this specification? > > I don't love that the suggested SASL mechanisms have no protection against > tokens being stolen and re-used via MITM, but this could be solved by using > SCRAM in implementations which is not forbidden. > > >5. Is the specification accurate and clearly written? > > I do not particularly like at all having the SASL mechanisms for FAST > specified completely seperately. I do sort of understand the reason it was > does, but it's not generic at all. For example if I want do (and I do want > to) support "app passwords" I need to solve the same problems (select which > credential is being used, specify which SASL mechanisms can be used for > which credential) but I wouldn't be able to re-use the solution FAST uses > and would need yet another third solution. I guess that depends a lot on what exactly your vision for "app passwords" is but if they don’t renew themselves and aren’t necessarily requested via XMPP you can just use SASL2 with PLAIN for example and already get the 0rtt parts. (I actually have a deployment where we use PLAIN anyway and thus never felt the need to use FAST after we got SASL2+Bind2) I mean FAST is really just a thin wrapper around a family of SASL mechanisms so I don’t get the point that it is too narrowly defined around those mechanisms. But I guess if you feel strongly spec out what you need for "app passwords" and we can look at the concrete overlap. cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
