Tweak nonce requirements #340
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- 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
cjpatton
approved these changes
May 2, 2024
|
|
divergentdave
approved these changes
May 2, 2024
cjpatton
requested changes
May 2, 2024
tgeoghegan
added a commit
to ietf-wg-ppm/draft-ietf-ppm-dap
that referenced
this pull request
May 2, 2024
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 <cpatton@cloudflare.com>
divergentdave
approved these changes
May 8, 2024
cjpatton
approved these changes
May 8, 2024
|
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. |
tgeoghegan
added a commit
to ietf-wg-ppm/draft-ietf-ppm-dap
that referenced
this pull request
May 8, 2024
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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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