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 > <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
