Re: LAST CALL: XEP-0484 (Fast Authentication Streamlining Tokens)

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]