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.
For example, the latest version of the HT draft adds a 0x00/0x01 prefix to the responder message to indicate success or failure. I suggest to do a namespace bump of FAST once the HT I-D becomes an RFC and then reference that RFC in FAST. -tmolitor Am Montag, 24. Februar 2025, 12:41:48 CET schrieb Florian Schmaus: > On 13/02/2025 12.00, Matthew Wild wrote: > > > On Thu, 13 Feb 2025 at 10:42, Florian Schmaus <[email protected]> wrote: > > > >>>> 1: See also the relevant paragraph about 0-RTT in > >>>> https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#n > >>>> ame-initiator-first-message >>> > >>> > >>> > >>> I think this text is overly restrictive, as explained above. > >> > >> > >> > >> I am sorry, but I don't think it was explained above. But I now > >> understand that your mental model regarding 0-RTT data differs from > >> mine. > >> > >> > >> > >> I am surprised that the FAST XEP mentions the issue with side effects > >> causing data in the 0-RTT payload, explaining that the counter would fix > >> that completely. That is not the case if the attacker removes the > >> original 0-RTT packet from the wire. It seems to be consensus by the TLS > >> designers that 0-RTT payload should only cause an idempotent operation. > >> But if we need replay protection, then the operation we protect is not > >> idempotent, as otherwise, we wouldn't need replay protection. > > > > > > Sorry, I think I understand now. The missing part is the assumption > > that the attacker will block the original handshake and that client > > will retry on failure. So the repeated transmission is actually coming > > from the client itself generating a new packet, not from the attacker > > duplicating things. > > > Not only that. > > The attacker could "hold" the original packet and the client will run > into a timeout, potentially assuming that the packet did not reach the > server and that the "commands" in the packet where not executed. > Afterwards, the attacker could replay the packet, causing the packet's > "commands" to be executed. This could leave the client in a state where > its assumption about what happened to be different from what actually > happened. > > For example, the client may appear online to others, while it considers > itself being offline. > > This can just be fixed by only including the data required for > authentication in the 0-RTT packet and performing everything else, in > particular resource binding, in a subsequent step. > > > > > If the client does not increase the count unless the server responds > > with <success/>, doesn't that fix this issue? But my confidence is > > certainly decreasing at this point. > > > The only fix is for the 0-RTT data to exclusively contain material used > for authentication. Then an attack replaying the packet could "just" > authenticate the connection, but this connection would be unusable for > the attacker as they don't actually possess the TLS key material. > > > > > I generally dislike the use of timestamps for things like this. Either > > something is safe, or it's not. Reducing the unsafe part to a small > > time window is almost certainly going to remain unacceptably unsafe in > > some circumstances. > > > > > >> I believe you want to reduce XMPPs initial connection and authentication > >> delay as much as I do. But the 0-RTT data should only contain what is > >> necessary for (fast re-)authentication. Everything else should be done > >> in a subsequent [1], i.e., in the 1.5 round trip, which is a small price > >> to pay for the security you gain. As bonus, replay protection becomes a > >> non-issue for FAST. > > > > > > FWIW I do care about round trips, but I'm not trying to be fanatical > > about it :) I don't think anyone implements 0-RTT at this point, and I > > don't know how much anyone actually cares right now, considering the > > other savings we've already achieved. > > > Right, but there is no need to close the door on 0-RTT yet. We need some > more implementation experience before we decide that. But as of now, we > certainly should not force 0-RTT implementers to shove more than the > data required for authentication into the 0-RTT packet. > > - Flow _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
