-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tweak nonce requirements #340
Conversation
- Clarify that aggregators must verify that nonces are never re-used. Since VDAF aims to provide privacy in the face of malicious clients, it doesn't suffice to say clients MUST generate nonces using a CSPRNG; we have to account for malicious clients by adding a MUST for the aggregator. This lines up with the behavior DAP has specified for a long time now. - In the second paragraph, clarify that over exposing a *report* is the risk, not a *measurement*. It's always possible for the same measurement to occur many times (for instance, in `Prio3Count`, most measurements are 1), but we want the enclosing *report* to be unique. See ietf-wg-ppm/draft-ietf-ppm-dap#558 for discussion
|
Discuss explicitly the attack prevented by enforcing unique report IDs, which is to stop honest Client reports from being replayed. This would also be necessary to satisfy VDAF's requirement of nonce uniqueness, but it's not yet clear VDAF will impose that exact requirement (see [1]). There's no functional change here, but hopefully being explicit can short-circuit future discussion of why we have this expensive requirement. See #558 for motivating discussion. [1]: cfrg/draft-irtf-cfrg-vdaf#340 (comment)
Co-authored-by: Christopher Patton <[email protected]>
Ah, I forgot that the draft already reacommended using the nonce for replay protection, and that this just adds clarity to this. Looks like we're good to go! I'm gonna merge, and I don't think there's a need for a second PR. |
Discuss explicitly the attack prevented by enforcing unique report IDs, which is to stop honest Client reports from being replayed. This would also be necessary to satisfy VDAF's requirement of nonce uniqueness, but it's not yet clear VDAF will impose that exact requirement (see [1]). There's no functional change here, but hopefully being explicit can short-circuit future discussion of why we have this expensive requirement. See #558 for motivating discussion. [1]: cfrg/draft-irtf-cfrg-vdaf#340 (comment)
Clarify that aggregators must verify that nonces are never re-used. Since VDAF aims to provide privacy in the face of malicious clients, it doesn't suffice to say clients MUST generate nonces using a CSPRNG; we have to account for malicious clients by adding a MUST for the aggregator. This lines up with the behavior DAP has specified for a long time now.
In the second paragraph, clarify that over exposing a report is the risk, not a measurement. It's always possible for the same measurement to occur many times (for instance, in
Prio3Count
, most measurements are 1), but we want the enclosing report to be unique.See ietf-wg-ppm/draft-ietf-ppm-dap#558 for discussion