Draft: draft-ppm-protocol

Commentary: We have the following security / operational considerations , not all of which can be addressed at the same time : Enforcing privacy budgets for DP requires us to limit the number of batches the same report is used . Hits requires the same report to be used in some number of batches . To resolve these issues , this change adds a parameter , which specifies the maximum number of times a report may be aggregated into an output . This enables Hits while allowing PPM protocols to enforce a privacy budget . This change also seeks to clarify some ambiguities in how the batch boundaries are defined , and why they 're defined that way . Along the way , it cleans up some protocol bits that got lost in the last refactor . by doing nothing . Hopefully the new text makes the issue more clear . 
 Rebased . 
 Squashed . 
 The current text has two batch constraints : This seems like it could have the result that collection is impossible . Suppose that we have : And reports come in at an average of 1 / s. In this case it would n't be possible to satisfy these constraints because you would never be able to accumulate 7200 reports . More generally , it 's not clear to me why should be a maximum rather than a minimum . How does that assist the helper / leader . ISTM we should either have one constraint ( probably ) or two but have them both be minimums . In either case , we probably want some way for the collector to learn when the limits are reached rather than having to poll . 
  , I wonder if we can get away with a single constraint ( batchsize ) under the assumption that reports are totally ordered before aggregation ? ( Do we need to distinguish between intra- and inter - replay attacks in this case ? ) That would be simpler overall , I think . 
  , the glossary says : So we need to decide which it is . 
 Finishing up a PR For this now . Just to be clear , the intent was to enforce a minimum batch window , not a maximum . So I think the reference above is a typo . 
 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 
 A few more nits but basically LGTM once any occurrence of " batch window " is corrected .
Paragraph (version A):
"batch_size": The batch size, i.e., the minimum number of reports
that are aggregated into an output.
Paragraph (version A):
"batch_window": The window of time covered by a batch, i.e., the
maximum interval between the oldest and newest report in a batch.
Paragraph (version B):
"max_batch_lifetime": The maximum number of times a batch of
reports may be used in a collect request.
Paragraph (version B):
"min_batch_size": The minimum batch size, i.e., the minimum number
of reports that appear in a batch.
Paragraph (version A):
where "pk" is the HPKE public key encoded by the collector's HPKE key
configuration, "task_id" is "OutputShareReq.task_id" and
"aggregator_id" is the index of the helper's endpoint in
"Param.aggregator_endpoints". "output_share" is the serialized
"OutputShare". "batch_start" and "batch_end" are obtained from the
"OutputShareReq".
Paragraph (version B):
"task_id" is the task ID associated with the PPM parameters.
Paragraph (version B):
"batch_interval" is the batch interval of the request.
Paragraph (version B):
"helper_state" is the helper's state, which is carried across
requests from the leader.
Paragraph (version B):
where "pk" is the HPKE public key encoded by the collector's HPKE key
configuration, "task_id" is "OutputShareReq.task_id" and
"aggregator_id" is the index of the helper's endpoint in
"Param.aggregator_endpoints". "output_share" is the serialized
"OutputShare", and "batch_interval" is obtained from the
"OutputShareReq".
Paragraph (version B):
"task_id", the task ID associated with the PPM parameters "Param".
Paragraph (version B):
"batch_interval", the request's batch interval.
Paragraph (version B):
The remainder of the message is dedicated to the protocol-specific
request parameters.
Paragraph (version B):
Depending on the PPM scheme and how the leader is configured, the
collect request may cause the leader to send a series of aggregate
requests to the helpers in order to compute their share of the
output.  Alternately, the leader may already have made these requests
and can respond immediately.  In either case it responds to the
collector's request as follows.
Paragraph (version A):
"shares" is a vector of "EncryptedOutputShare"s, as described in
output-share-request, except that for the leader's share, the
"task_id", "batch_start", and "batch_end" used to encrypt the
"OutputShare" are obtained from the "CollectReq".
Paragraph (version B):
"shares" is a vector of "EncryptedOutputShare"s, as described in
output-share-request, except that for the leader's share, the
"task_id" and "batch_interval" used to encrypt the "OutputShare"
are obtained from the "CollectReq".
Paragraph (version B):
Before an aggregator responds to a collect request or output share
request, it must first check that the request does not violate the
parameters associated with the PPM task.  It does so as described
here.
Paragraph (version B):
First the aggregator checks that the request's batch interval
respects the boundaries defined by the PPM parameters "Param".
Namely, it checks that both "batch_interval.start" and
"batch_interval.end" are divisible by "Param.min_batch_duration" and
that "batch_interval.end - batch_interval.start >=
min_batch_duration".  Unless both these conditions are true, it
aborts and alerts the peer with "invalid batch interval".
Paragraph (version B):
Next, the aggregator checks that the request respects the generic
privacy parameters of the PPM task.  Let "X" denote the set of input
shares the aggregator has validated and which fall in the batch
interval of the request.
Paragraph (version B):
If "len(X) < Param.min_batch_size", then the aggregator aborts and
alerts the peer with "insufficient batch size".
Paragraph (version B):
The aggregator keeps track of the number of times each input share
was added to the batch of an output share request.  If any input
share in "X" was added to at least "Param.max_batch_lifetime"
previous batches, then the helper aborts and alerts the peer with
"request exceeds the batch's privacy budget".
Paragraph (version B):
Using a report multiple times within a single batch, or using the
same report in multiple batches, is considered a privacy violation.
To prevent such replay attacks, this specification defines a total
ordering on reports that aggregators can use to ensure that reports
are aggregated once.
Paragraph (version B):
To prevent replay attacks, each aggregator ensures that each report
it aggregates follows the previously aggregated report.  To prevent
the adversary from tampering with the ordering of reports, honest
clients incorporate the ordering-sensitive parameters "(time, nonce)"
into the AAD for HPKE encryption.  Note that this strategy may result
in dropping reports that happen to have the same timestamp and nonce
value.
Paragraph (version B):
Aggregators prevent the same report from being used in multiple
batches (except as required by the protocol) by only responding to
valid collect requests, as described in batch-parameter-validation.
Paragraph (version A):
Store helper state associated with a given Param batch.
Paragraph (version B):
Store helper state.
Paragraph (version B):
Not all PPM tasks have the same operational requirements, so the
protocol is designed to allow implementations to reduce operational
costs in certain cases.
Paragraph (version B):
The PPM parameters also specify the maximum number of times a report
can be used.  Some protocols, such as Hits, require reports to be
used in multiple batches spanning multiple collect requests.
Paragraph (version A):
against malicious servers, but cannot provide robustness against
malicious servers.  Any aggregator can simply emit bogus output
shares and undetectably spoil aggregates.  If enough aggregators were
available, this could be mitigated by running the protocol multiple
times with distinct subsets of aggregators chosen so that no
aggregator appears in all subsets and checking all the outputs
against each other.  If all the protocol runs do not agree, then
participants know that at least one aggregator is defective, and it
may be possible to identify the defector (i.e., if a majority of runs
agree, and a single aggregator appears in every run that disagrees).
See #22 [2] for discussion.
Paragraph (version B):
Most PPM protocols, including Prio and Hits, are robust against
malicious clients, but are not robust against malicious servers.  Any
aggregator can simply emit bogus output shares and undetectably spoil
aggregates.  If enough aggregators were available, this could be
mitigated by running the protocol multiple times with distinct
subsets of aggregators chosen so that no aggregator appears in all
subsets and checking all the outputs against each other.  If all the
protocol runs do not agree, then participants know that at least one
aggregator is defective, and it may be possible to identify the
defector (i.e., if a majority of runs agree, and a single aggregator
appears in every run that disagrees).  See #22 [2] for discussion.
Paragraph (version A):
Using a report in multiple batches, or multiple times within a single
batch, is considered a privacy violation, since it may leak more
information about that report than intended by the PPM protocol.  For
example, this may violate differential privacy.  To mitigate this
issue, the core specification imposes an ordering on reports so that
aggregators can cheaply prevent replays attacks.
Paragraph (version A):
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, nonce)" into
the AAD for HPKE encryption.  Note that this strategy may result in
dropping reports that happen to have the same timestamp and nonce
value.
Paragraph (version A):
Aggregators prevent the same report from being used in multiple
batches by only consuming valid collect requests, as described in pa-
collect.