cac/protocol: make challenge-response completion idempotent across phase transitions

[Zk2u]

Summary

There is a liveness bug at the boundary between challenge-response completion and table-transfer setup.

The garbler remains in SendingChallengeResponse until all challenge-response send acknowledgments have been processed. The evaluator, however, can consume and verify the full challenge response and advance into the next phase before the garbler has finished receiving all of those ack completions.

If a delayed or duplicate challenge-response message arrives after the evaluator has advanced, the evaluator can treat it as UnexpectedInput. At that point the inbound stream is left unacked, and the garbler can wait forever for an acknowledgment that will never arrive.

This issue is about making this protocol boundary robust under delayed, duplicated, or retried delivery.

Correct model

The protocol must remain live under:

• delayed delivery
• duplicate delivery
• partial progress followed by retry/replay
• skew between sender-side completion tracking and receiver-side phase transition

A message that was valid in the immediately preceding phase must not be able to permanently wedge the protocol just because the receiver advanced slightly earlier than the sender.

The correct behavior is:

1. Delayed or duplicate challenge-response delivery after evaluator advancement

• harmlessly acknowledged/ignored, or
• otherwise surfaced in a way that still lets the sender complete the phase

2. Sender-side phase completion

• must not depend on a receiver behavior that becomes impossible as soon as the receiver advances to the next valid phase

Desired solution

1. Audit the full boundary between:

• garbler finishing SendingChallengeResponse
• evaluator consuming/verifying the response
• evaluator entering the next phase

2. Make challenge-response receipt idempotent across that boundary.
3. Remove any path where a delayed valid challenge-response message becomes a permanent liveness failure.
4. Review whether the garbler’s requirement to process every protocol-level send acknowledgment before advancing is too strict for the runtime model.
5. Audit UnexpectedInput handling around this transition and reclassify any cases where delayed valid traffic should instead be tolerated.

The exact implementation is open, but the result must be that staggered starts, duplicate delivery, or delayed in-flight messages cannot strand one side in SendingChallengeResponse while the other has already moved on.

Scope of this issue

1. Audit garbler STF transition logic around challenge-response send completion.
2. Audit evaluator STF handling of challenge-response traffic after local advancement.
3. Audit inbound protocol request handling and ack behavior where STF returns an error.
4. Add tests for reordered/duplicated challenge-response delivery across the phase transition.

Acceptance criteria

• A protocol instance cannot wedge with garbler in SendingChallengeResponse and evaluator in a later phase solely due to delayed or duplicate challenge-response traffic.
• Delayed/duplicate challenge-response messages are tolerated in a way that preserves liveness.
• The boundary between challenge-response and table-transfer phases is robust under realistic retry/reordering behavior.
• Tests cover duplicate and delayed message delivery across the phase transition.