Draft: draft-pda-protocol

Commentary: For privacy reasons , leaders should not be allowed to replay a given report more than once within the context of a single batch . The current verify+collect model runs in a " streaming mode , " wherein the leader sends slices of batch shares to helpers for verification and aggregation . If we changed this to require the leader to send all batch shares in a single verify+collect flow , then replay prevention would be simpler : just scan the list and check for dupes . If we stick with the current model , then the helper must necessarily store some state ( on the leader , most likely ) representing the shares processed . This state could then be consulted when asked to verify+collect any new share . ( We can probably spell out a number of ways to do store this state , but ideally it should not be linear in the number of shares collected so far . ) We 'd likely also need a way for the leader to request that the helper produce the final aggregate output once the batch is " done " being verified and collected . 
 One downside to this approach is that it requires the leader to queue up the entire batch of reports before sending the first aggregate request to the helper . This may be OK for some deployments , but it might not be workable for all . I think this is worth pursuing . This is already in the protocol . ( See " output share request " . ) 
 We could require that the leader feed the helper reports with monotonically increasing timestamps , such that the helper can simply maintain a single timestamp and reject any report older than that . However I 'm not sure if that 's practical given that clients may submit reports out of order . 
 One intermediate option would be to maintain a jitter buffer on the leader , so that they keep reports for a few minutes and then feed them out in order . You would still lose some reports , but not too many . 
 I have a few questions but nothing blocking .
Paragraph (version B):
"task_id" is the task ID of the task for which the report is
intended.
Paragraph (version B):
"encrypted_input_shares" contains the encrypted input shares of
each of the aggregators.
Paragraph (version A):
where "input_share" is the aggregator's input share.
Paragraph (version B):
where "input_share" is the aggregator's input share and "task_id",
"time", and "jitter" are the fields of "PDAReport".
Paragraph (version A):
The "helper_share" field is the helper's encrypted input share as it
appeared in the report uploaded by the client.  [OPEN ISSUE: We
usually only need to send this in the first aggregate request.  Shall
we exclude it in subsequent requests somehow?]  The "time" field
should match the timestamp of the corresponding report.  The
remainder of the structure is dedicated to the protocol-specific
helper share and request parameters used for the current round.
Paragraph (version A):
The helper handles well-formed requests as follows.  (As usual,
malformed requests are handled as described in pa-error-common-
aborts.)  It first looks for the PDA parameters "PDAParam" for which
"PDAAggregateReq.task_id" is equal to the task ID derived from
"PDAParam".
Paragraph (version B):
The "time" and "jitter" fields have the same value as those in the
report uploaded by the client.  Similarly, the "helper_share" field
is the helper's encrypted input share as it appeared in the report.
[OPEN ISSUE: We usually only need to send this in the first aggregate
request.  Shall we exclude it in subsequent requests somehow?]  The
remainder of the structure is dedicated to the protocol-specific
request parameters.
Paragraph (version B):
In order to provide replay protection, the leader is required to send
aggregate sub-requests in ascending order, where the ordering on sub-
requests is determined by the algorithm defined in anti-replay.
Specifically, the leader constructs its request such that: * each
sub-request follows the previous sub-request; and * the first sub-
request follows the last sub-request in the previous aggregate
request.
Paragraph (version A):
where "sk" is the HPKE secret key.  If decryption fails, then the
sub-response consists of a "decryption error" alert.  [See issue#57.]
Otherwise, the helper handles the request for its plaintext input
share "input_share" and updates its state as specified by the PDA
protocol.
Paragraph (version B):
where "sk" is the HPKE secret key and "server_role" is the role of
the server ("0x01" for the leader and "0x00" for the helper).  If
decryption fails, then the sub-response consists of a "decryption
error" alert.  [See issue#57.]  Otherwise, the helper handles the
request for its plaintext input share "input_share" and updates its
state as specified by the PDA protocol.
Paragraph (version B):
The leader is required to issue aggregate requests in order, but
reports are likely to arrive out-of-order.  The leader SHOULD buffer
reports for a time period proportional to the batch window before
issuing the first aggregate request.  Failure to do so will result in
out-of-order reports being dropped by the helper.
Paragraph (version B):
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 PDA 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 B):
Aggregate requests are ordered as follows: We say that a report "R2"
_follows_ report "R1" if either "R2.time > R1.time" or "R2.time ==
R1.time" and "R2.jitter > R1.jitter".  If "R2.time < R1.time", or
"R2.time == R1.time" but "R2.jitter <= R1.jitter", then we say that
"R2" _does not follow_ "R1".
Paragraph (version B):
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 B):
Note that this strategy may result in dropping reports that happen to
have the same timestamp and jitter value.