Draft: draft-ietf-ppm-dap

Commentary: Clarify that is used when it 's impossible to determine if an input share is valid . One situation we need this for is when an Aggregator drops some anti - replay state in order to reduce storage costs . This should result in data loss in the worst case , not a loss of privacy . 
 Since , aggregators are required to store report nonces for batch intervals that have not yet been collected . This is necessary in order to prevent replay attacks . The problem is that nothing guarantees that a batch interval will be collected in a timely manner : In theory , it 's possible that aggregators will have to store nonce sets indefinitely . To prevent this , there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval . The strawman solution is to allow each aggregator to , at its own discretion , ignore a report if it ca n't confirm if the report was replayed or not . The problem is that this potentially leads to unnecessary data loss . 
 I propose resolving this with .
Paragraph (version A):
The Leader MUST ignore any report pertaining to a batch that has
already been collected.  (See input-share-batch-validation for
details.)  Otherwise, comparing the aggregate result to the previous
aggregate result may result in a privacy violation.  (Note that the
Helpers enforce this as well.)  The Leader MAY ignore any reports
whose timestamp is past the task's "task_expiration".  When it does
so, the leader SHOULD abort the upload protocol and alert the client
with error "reportTooLate".  Client MAY choose to opt out of the task
if its own clock has passed "task_expiration".
Paragraph (version B):
The Leader MUST ignore any report pertaining to a batch that has
already been collected.  (See early-input-share-validation for
details.)  Otherwise, comparing the aggregate result to the previous
aggregate result may result in a privacy violation.  (Note that the
Helpers enforce this as well.)  The Leader MAY ignore any reports
whose timestamp is past the task's "task_expiration".  When it does
so, the leader SHOULD abort the upload protocol and alert the client
with error "reportTooLate".  Client MAY choose to opt out of the task
if its own clock has passed "task_expiration".
Paragraph (version A):
The validation checks are as follows.
Paragraph (version B):
Before beginning the preparation step, Aggregators are required to
perform the following generic checks.
Paragraph (version A):
Check if the report has already been aggregated with this
aggregation parameter.  If this check fails, the input share MUST
be marked as invalid with the error "report-replayed".  This is
the case if the report was used in a previous aggregate request
and is therefore a replay.  An aggregator may also choose to mark
an input share as invalid with the error "report-dropped" under
the conditions prescribed in anti-replay.
Paragraph (version B):
Check if the report has already been aggregated with this
aggregation parameter.  If this check fails, the input share MUST
be marked as invalid with the error "report-replayed".  This is
the case if the report was used in a previous aggregate request
and is therefore a replay.
Paragraph (version B):
If all of the above checks succeed, the input share is not marked as
invalid.
Paragraph (version A):
To detect replay attacks, each aggregator keeps track of the set of
nonces pertaining to reports that were previously aggregated for a
given task.  If the leader receives a report from a client whose
nonce is in this set, it either ignores it or aborts the upload sub-
protocol as described in upload-flow.  A Helper who receives an
encrypted input share whose nonce is in this set rejects the report
as described in input-share-batch-validation.
Paragraph (version B):
To detect replay attacks, each aggregator keeps track of the set of
nonces pertaining to reports that were previously aggregated for a
given task.  If the leader receives a report from a client whose
nonce is in this set, it either ignores it or aborts the upload sub-
protocol as described in upload-flow.  A Helper who receives an
encrypted input share whose nonce is in this set rejects the report
as described in early-input-share-validation.
Paragraph (version B):
However, Aggregators are also required to implement several per-
report checks that require retaining a number of data artificts.  For
example, to detect replay attacks, it is necessary for each
Aggregator to retain the set of nonces of reports that have been
aggregated for the task so far.  Depending on the task lifetime and
report upload rate, this can result in high storage costs.  To
elliviate this burden, DAP allows Aggregators to drop this state as
needed, so long as reports are droppped properly as described in
early-input-share-validation.  Aggregators SHOULD take steps to
mitigate the risk of dropping reports (e.g., by evicting the oldest
data first).