13 Feb
2025
13 Feb
'25
4 a.m.
On Thu, 13 Feb 2025 at 10:42, Florian Schmaus <flo(a)geekplace.eu> wrote:
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.
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.
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.
1: See also the relevant paragraph about 0-RTT in
https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-…
I think this text is overly restrictive, as explained above. 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.
Regards,
Matthew