4 Feb
2025
4 Feb
'25
9:57 a.m.
On Tue, Feb 4, 2025 at 4:02 PM Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
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
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.