12 Dec
2025
12 Dec
'25
10:45 p.m.
Given that the "counter" for FAST does nothing to prevent replay attacks (see
flows mails in this thread) and nobody currently implements 0rtt (afaik), I'd
say we remove the whole 0rtt from the spec.
We can always create a dedicated 0rtt spec later on if we feel this is needed
(and the security part of it has been sorted out appropriately).
This means we can remove the <fast> element inside the <authenticate> element
altogether since this was only there to communicate the counter and the SASL
mechanism name already conveys we are using FAST.
I can draft a PR to do this :)
Regarding the HT token reference: yes, we should try harder to advance that at
the IETF. Daniel, your presence at IETF125 could help there. I won't be able
to attend, but I'm willing to help remotely :)
-tmolitor
Am Freitag, 12. Dezember 2025, 15:43:26 CET schrieb Daniel Gultsch:
Hi,
On Fri, Dec 12, 2025 at 4:03 AM Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
>
>
> >I know the last call is already over, but we should not advance that
> >spec
> >to
> >stable until the underlying I-D for HT tokens is stable.
>
>
>
> This is a good thought, but fast doesn't rely on or mandate HT so I dint
> think it affects the xep per se?
>
>
>
> I'm aware that in prrctise implementations are using HT before it is
> stable
which is a problem for these implementations.
couple of things: I think FAST is adding some real benefit to the
ecosystem. I believe three servers have support for it and a forth one
is currently working on the implementation. I think we should do our
best to try to advance this XEP one way or another.
As a community we should try to avoid having slightly imperfect things
that are widely deployed and clearly useful but are stagnated due
their imperfectness. (I think for a while Carbons was a good example
for what I think we should try to avoid)
As Stephen pointed out the XEP is _technically_ independent of Hashed
Tokens (but also not really in practice).
Implementing HT before it becomes stable is something one can probably
just deal with. I don’t think it posses major challenges (at least not
with the changes that have been made so far)
However the IETF isn’t a magical place where we send HT to and just
wait for them to do their job. Kitten is not a super active WG and we
(the XMPP community) are a major stake holder in SASL (one of the few
stake holders that there are). So if we want this to go through the
IETF it is us (our community) that needs to actively push it through
the WG and the process.
So if we have community consensus that we want an HT RFC before we
stabilize FAST we need to get active here. I will be at IETF125 in
Shenzhen in March. Maybe we can convince the Kitten WG to have a
meeting there (They didn’t have a meeting at the last two IETFs) but I
would also appreciate additional support from people who have more
experience with the IETF on how we can get HT trough.
I guess the second open question for this XEP is whether or not the
0rtt is appropriate for which my personal answer is I just don’t know.
I can write an implementation because Java lacks the API so I guess we
have to wait for people like Thilo to provide their input on that.
cheers
Daniel
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org