Draft: draft-pda-protocol

Commentary: This partially addresses the problem of preventing inter - batch replay attacks described by in . Along the way , clean up the description of collect requests so that it talks about protocol messages rather than API calls ( as suggested ) . 
 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
Paragraph (version A):
The collector interacts with the leader to produce the final
aggregate output.  This process consists of a sequence of _collect
requests_ issued to the leader.  Before a request can succeed, the
aggregators must have verified and aggregated enough reports and the
leader must have obtained the helper's encrypted output share (see
pa-aggregate).  In general, the procedure by which the aggregators
verify and aggregate reports depends on parameters carried by the
collect request.  This procedure is described below in pa-aggregate.
Paragraph (version A):
CreateRequest(): Creates a PDACollectReq object, defined below,
that is sent to the leader to complete one iteration of the
protocol.  Along with any protocol-specific parameters, the
message specifies a time interval "[batch_start, batch_end)" that
determines the batch of reports to be aggregated.  It must be that
"batch_end - batch_start >= PDAParam.batch_window" and
"batch_start" and "batch_end" are multiples of
"PDAParam.batch_window".
Paragraph (version A):
Update(resp: PDACollectResp): Consumes an opaque PDACollectResp
object, defined below, that is received from the leader in
response to a PDACollectReq.
Paragraph (version A):
Finished(): Returns a boolean indicating indicating whether or not
the collection procedure is complete.  This function returns true
when the collect iteration is complete.
Paragraph (version A):
Output(): Returns the aggregate output corresponding to the
protocol.
Paragraph (version B):
The collector interacts with the leader to produce the final
aggregate output.  This process consists of a sequence of _collect
requests_ issued to the leader.  Before a request can succeed, the
aggregators must have verified and aggregated enough reports and the
leader must have obtained the helper's encrypted output share (see
pa-aggregate).  In general, the procedure by which the aggregators
verify and aggregate reports depends on parameters carried by the
collect request.
Paragraph (version B):
The batch window of the request aligns with the size of the batch
window for the task, i.e., "batch_start" and "batch_end" are
multiples of "PDAParam.batch_window".
Paragraph (version B):
The batch window of the request is at least the minimum batch
window for the task, i.e., "batch_end - batch_start >=
PDAParam.batch_window".
Paragraph (version A):
To prevent replay attacks, it suffices for each aggregator to ensure
that each report it consumes follows the previous one it consumed.
To prevent the adversary from tampering with the ordering of reports,
honest clients incorporate the ordering-sensitive parameters "(time,
jitter)" into the AAD for HPKE encryption.
Paragraph (version A):
Note that this strategy may result in dropping reports that happen to
have the same timestamp and jitter value.
Paragraph (version B):
To prevent replay attacks, each aggregator ensures that each report
it consumes follows the previous one it consumed.  To prevent the
adversary from tampering with the ordering of reports, honest clients
incorporate the ordering-sensitive parameters "(time, jitter)" into
the AAD for HPKE encryption.  Note that this strategy may result in
dropping reports that happen to have the same timestamp and jitter
value.
Paragraph (version B):
Aggregators prevent the same report from being used in multiple
batches by only consuming valid collect requests, as described in pa-
collect.