24 Feb
2025
24 Feb
'25
6:41 a.m.
On 13/02/2025 12.00, Matthew Wild wrote:
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.
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.
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.
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.
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
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.