On 10/02/2025 18.07, Matthew Wild wrote:
On Wed, 5 Feb 2025 at 16:24, Florian Schmaus <[email protected]> wrote:> 4. Do you have any security concerns related to this specification?The XEP states that the 'count' attribute protects against replay attacks if TLS' 0-RTT data is used. I am not sure if this is true. An attacker could take the original 0-RTT package from the wire and replay it against the server. How does 'count' help here?Per the XEP, the server rejects subsequent packets with a 'count' less than or equal to what it has already seen.What is essential is that 0-RTT data only contains the authentication data, but nothing more [1]. If it would contain, for example, also a correctly pipelined <message/>, then an attacker could potentially replay the 0-RTT data and cause the server to send the message.I don't think this matters, if the server correctly rejects the authentication. Servers already need to ensure they don't process pipelined data on failed authentications (with or without 0-RTT).
But in the scenario I depicted, the authentication would succeed.
Further remarks: Shouldn't token invalidation be possible without having to go through a SASL authentication? I am at a kiosk browser and hit the 'logout' button. Now the browser first has to disconnect and reconnect to invalidate the token?Yes, I agree this is a bit awkward. We should spec a way to do this after authentication, e.g. with a simple iq.
+1
1: See also the relevant paragraph about 0-RTT in https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-initiator-first-messageI 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.
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.
If you really want to go down that route, then at least consider adding a timestamp. This would reduce the time window for an attacker to replay the packet. The timestamp could replace the counter, be in addition to it, or even be optional.
Hopefully this does not come over as overly negative. I really appreciate your work on FAST. I only disagree on technical grounds on how 0-RTT is used in FAST.
- Flow 1: This probably needs support from Bind 2
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
