Re: [w3ctag/design-reviews] Private Proof API (Issue #1071)

toreini left a comment (w3ctag/design-reviews#1071)

Hi @SamuelSchlesinger,

many thanks for your response. yes, I can see that the proof of ownership is sent instead of the private k in the spec text, but please make your protocol diagram more accurate. However, here is my current concern.

If a malicious actor can get access to the RateLimitingToken and the proof, then I think it can relay/replay the token later if it is not bound to something. You are essentially relying on the epoch_length and epoch_limit in the verification algorithm to mitigate the distribution attacks but these two parameters are deterministic. I assume you are holding on economy of scale and say each token cannot be relayed/replayed more than x times, accepting the risk of *some* fraud actors here and there, but not a large-scale campaign.

Essentially, my question is this: **Is the relaying/replaying attack possible if a malicious actor get access to a legit token and proof?** If the verification relies on epoch_length and epoch_limit, and they are predictable (which I think they are), then my concern is that if a small/medium fraud campaign or a clever big campaign can successfully bypass the current protocol if they have a collection of valid "RateLimitingToken and the proof". Even in case of using ring signature for issuer fungibility, as described in honest token sharing, collusion can be possible.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1071#issuecomment-3132494518
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1071/3132494518@github.com>