Draft: draft-ietf-ppm-dap

Commentary: Similar to , it should not be possible for a share to be included in more than one batch . The timestamp currently gives us some way of ensuring that reports map to at most batch , but not a way of ensuring that reports are n't included two overlapping batch windows . It 's not immediately clear if include a single report in two overlapping batch windows is a problem , or if a problem only arises when these windows are disjoint . We should probably clarify what are the inter - batch requirements here and what sort of replay prevention is required . 
 The aggregators ( either the leader or helper ) can prevent the collector from getting outputs from overlapping batches by remembering batch intervals . For example , suppose the leader responded successfully to a collect request for time interval . Then suppose that , some time later , the collector requests output shares for , where . The potential privacy violation occurs because the sets of reports in each batch are non - disjoint . To prevent this , the leader might respond to the second request with an error , or it might just include the reports in . 
 If aggregators are meant to use the report timestamp to protect against replay , then I think it needs to appear in the AEAD - ed message constructed by the client ( i.e. ) . Otherwise a leader could insert arbitrary timestamps into and trick helpers into exceeding privacy budgets or double counting inputs . Additionally , a batching client could insert arbitrary values into . 
 I created a PR that addresses this issue partially . What 's left to do is allow multiple collect requests over the same batch , as required by the PDA protocol ( e.g. ,  ) . I have an idea for how to do this , I 'll follow up with a PR . 
 Closed by 
 LGTM -- thanks !
Paragraph (version A):
The aggregation function to compute (e.g., sum, mean, etc.) and an
optional aggregation parameter.
Paragraph (version B):
The aggregation function to compute (e.g., sum, mean, etc.).
Paragraph (version A):
The "nonce" and "extensions" fields of each ReportShare match that in
the Report uploaded by the client.  The "encrypted_input_share" field
is the "HpkeCiphertext" whose index in
"Report.encrypted_input_shares" is equal to the index of the
aggregator in the task's "aggregator_endpoints" to which the
AggregateInitializeReq is being sent.  The "agg_param" field is an
opaque, VDAF-specific aggregation parameter.  The "job_id" parameter
contains the leader's chosen AggregationJobID.
Paragraph (version B):
The "nonce" and "extensions" fields of each ReportShare match that in
the Report uploaded by the client.  The "encrypted_input_share" field
is the "HpkeCiphertext" whose index in
"Report.encrypted_input_shares" is equal to the index of the
aggregator in the task's "aggregator_endpoints" to which the
AggregateInitializeReq is being sent.  The "agg_param" field is an
opaque, VDAF-specific aggregation parameter provided during a
collection flow.  The "job_id" parameter contains the leader's chosen
AggregationJobID.
Paragraph (version B):
"agg_param", an aggregation parameter for the VDAF being executed.
This is the same value as in "AggregateInitializeReq" (see leader-
init).
Paragraph (version B):
"agg_param", an aggregation parameter for the VDAF being executed.
This is the same value as in "AggregateInitializeReq" (see leader-
init) and in "CollectReq" (see collect-init).