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#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.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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
