Draft: draft-pda-protocol

Commentary: Squashed . 
 LGTM modulo one nit
Paragraph (version A):
The protocol is executed by a large set of clients and a small set of
servers.  We call the servers the _aggregators_. Each client's input
to the protocol is a set of measurements (e.g., counts of some user
behavior).  Given the input set of measurements "x_1, ..., x_n" held
by "n" users, the goal of a _private aggregation (PA) protocol_ is to
compute "y = F(x_1, ..., x_n)" for some aggregation function "F"
while revealing nothing else about the measurements.
Paragraph (version B):
The protocol is executed by a large set of clients and a small set of
servers.  We call the servers the _aggregators_. Each client's input
to the protocol is a set of measurements (e.g., counts of some user
behavior).  Given the input set of measurements "x_1, ..., x_n" held
by "n" users, the goal of a _private data aggregation (PDA) protocol_
is to compute "y = F(x_1, ..., x_n)" for some aggregation function
"F" while revealing nothing else about the measurements.
Paragraph (version A):
To solve this problem, in each PA protocol, the client generates a
zero-knowledge proof of its input's validity that the aggregators use
to verify that their shares correspond to as valid input.  The
verification procedure is designed to ensure that the aggregators
learn nothing about the input beyond its validity.
Paragraph (version A):
After encoding its measurements as an input to the PA protocol, the
client generates a _proof_ of the input's validity.  It then splits
the proof into shares and sends a share of both the proof and input
to each aggregator.  The aggregators use their shares of the proof to
decide if their input shares correspond to a valid input.
Paragraph (version B):
To solve this problem, in each PDA protocol, the client generates a
zero-knowledge proof of its input's validity that the aggregators use
to verify that their shares correspond to as valid input.  The
verification procedure is designed to ensure that the aggregators
learn nothing about the input beyond its validity.
Paragraph (version B):
After encoding its measurements as an input to the PDA protocol, the
client generates a _proof_ of the input's validity.  It then splits
the proof into shares and sends a share of both the proof and input
to each aggregator.  The aggregators use their shares of the proof to
decide if their input shares correspond to a valid input.
Paragraph (version A):
Each PA task consists of two sub-protocols, _upload_ and _collect_,
which are executed concurrently.  Each sub-protocol consists of a
sequence of HTTP requests made from one entity to another.
Paragraph (version B):
Each PDA task consists of two sub-protocols, _upload_ and _collect_,
which are executed concurrently.  Each sub-protocol consists of a
sequence of HTTP requests made from one entity to another.
Paragraph (version A):
This section specifies a protocol for executing generic PA tasks.
Concrete PA protocols are described in prio and hits.
Paragraph (version B):
This section specifies a protocol for executing generic PDA tasks.
Concrete PDA protocols are described in prio and hits.
Paragraph (version A):
"proto": The PA protocol, e.g., Prio or Hits.  The rest of the
structure contains the protocol specific parameters.
Paragraph (version B):
"proto": The PDA protocol, e.g., Prio or Hits.  The rest of the
structure contains the protocol specific parameters.
Paragraph (version A):
The aggregators agree on a set of PA tasks, as well as the PA
parameters associated to each task.
Paragraph (version A):
Each client has selected a PA task for which it will upload a
report.  It is also configured with the task's parameters.
Paragraph (version B):
The aggregators agree on a set of PDA tasks, as well as the PDA
parameters associated to each task.
Paragraph (version B):
Each client has selected a PDA task for which it will upload a
report.  It is also configured with the task's parameters.
Paragraph (version A):
CreateRequest(): Creates a PACollectReq 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 >= PAParam.batch_window" and
"batch_start" and "batch_end" are multiples of
"PAParam.batch_window".
Paragraph (version A):
Update(resp: PACollectResp): Consumes an opaque PACollectResp
object, defined below, that is received from the leader in
response to a PACollectReq.
Paragraph (version B):
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 B):
Update(resp: PDACollectResp): Consumes an opaque PDACollectResp
object, defined below, that is received from the leader in
response to a PDACollectReq.
Paragraph (version A):
Each collect request involves one of the helpers specified by the PA
parameters.  If more than one helper is specified, the collector may
issue the requests in any order.
Paragraph (version B):
Each collect request involves one of the helpers specified by the PDA
parameters.  If more than one helper is specified, the collector may
issue the requests in any order.
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 PA parameters "PAParam" for which
"PAAggregateReq.task_id" is equal to the task id derived from
"PAParam".
Paragraph (version B):
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 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 PA
protocol.
Paragraph (version B):
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 A):
Once the aggregators have verified at least as many reports as
required for the PA task, the leader issues an _output share request_
to the helper.  The helper responds to this request by extracting its
output share from its state and encrypting it under the collector's
HPKE public key.
Paragraph (version B):
Once the aggregators have verified at least as many reports as
required for the PDA task, the leader issues an _output share
request_ to the helper.  The helper responds to this request by
extracting its output share from its state and encrypting it under
the collector's HPKE public key.
Paragraph (version A):
where "task" is the associated PA task (this value is always known)
and "payload" is the message.  When sent by an aggregator in response
to an HTTP request, the response status is 400.  When sent in a
request to an aggregator, the URL is always "[aggregator]/error",
where "[aggregator]" is the URL of the aggregator endpoint.
Paragraph (version B):
where "task" is the associated PDA task (this value is always known)
and "payload" is the message.  When sent by an aggregator in response
to an HTTP request, the response status is 400.  When sent in a
request to an aggregator, the URL is always "[aggregator]/error",
where "[aggregator]" is the URL of the aggregator endpoint.
Paragraph (version A):
Each POST request to an aggregator contains a "PATaskID".  If the
aggregator does not recognize the task, i.e., it can't find a
"PAParam" for which the derived task id matches the "PATaskID",
then it aborts and alerts the peer with "unrecognized task".
Paragraph (version B):
Each POST request to an aggregator contains a "PDATaskID".  If the
aggregator does not recognize the task, i.e., it can't find a
"PDAParam" for which the derived task id matches the "PDATaskID",
then it aborts and alerts the peer with "unrecognized task".