Draft: draft-ietf-ppm-dap

Commentary: Based on ( merge that first ) .
Paragraph (version A):
In order to address this problem, the aggregators engage in a secure,
multi-party computation specified by the chosen VDAF VDAF in order to
prepare a report for aggregation.  At the beginning of this
computation, each aggregator is in possession of an input share
uploaded by the client.  At the end of the computation, each
aggregator is in posession of either an "output share" that is ready
to be aggregated or an indication that a valid output share could not
be computed.
Paragraph (version A):
To facilitiate this computation, the input shares generated by the
client include information used by the aggregators during aggregation
in order to validate their corresponding output shares.  For example,
Prio3 includes a distributed zero-knowledge proof of the input's
validity BBCGGI19 which the aggregators can jointly verify and reject
the report if it cannot be verified.  However, they do not learn
anything about the individual report other than that it is valid.
Paragraph (version B):
In order to address this problem, the aggregators engage in a secure,
multi-party computation specified by the chosen VDAF VDAF in order to
prepare a report for aggregation.  At the beginning of this
computation, each aggregator is in possession of an input share
uploaded by the client.  At the end of the computation, each
aggregator is in possession of either an "output share" that is ready
to be aggregated or an indication that a valid output share could not
be computed.
Paragraph (version B):
To facilitate this computation, the input shares generated by the
client include information used by the aggregators during aggregation
in order to validate their corresponding output shares.  For example,
Prio3 includes a distributed zero-knowledge proof of the input's
validity BBCGGI19 which the aggregators can jointly verify and reject
the report if it cannot be verified.  However, they do not learn
anything about the individual report other than that it is valid.
Paragraph (version A):
A nonce used by the Aggregators to ensure the report appears in at
most one batch.  (See anti-replay.)  The Client MUST generate this
by generating 16 random bytes using a cryptographically secure
random number gnerator.
Paragraph (version B):
A nonce used by the Aggregators to ensure the report appears in at
most one batch.  (See anti-replay.)  The Client MUST generate this
by generating 16 random bytes using a cryptographically secure
random number generator.
Paragraph (version A):
Initialization: Begin the aggregation flow by sharing report
shares with each helper.  Each aggregator, including the leader,
initializates the underlying VDAF instance using these report
shares and the VDAF configured for the corresponding measurement
task.
Paragraph (version B):
Initialization: Begin the aggregation flow by sharing report
shares with each helper.  Each aggregator, including the leader,
initializes the underlying VDAF instance using these report shares
and the VDAF configured for the corresponding measurement task.
Paragraph (version A):
"vdaf_verify_key" is the VDAF verification key shared by the
aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and
"0x01" for the helper); "agg_param" is the opaque aggregation
parameter distributed to the aggregtors by the collector;
"public_share" is the public share generated by the client and
distributed to each aggregator; and "input_share" is the aggregator's
input share.
Paragraph (version B):
"vdaf_verify_key" is the VDAF verification key shared by the
aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and
"0x01" for the helper); "agg_param" is the opaque aggregation
parameter distributed to the aggregators by the collector;
"public_share" is the public share generated by the client and
distributed to each aggregator; and "input_share" is the aggregator's
input share.
Paragraph (version A):
Otherwise, the helper interpets "out" as the tuple "(new_state,
prep_msg)", where "new_state" is its updated preparation state and
"prep_msg" is its next VDAF message.
Paragraph (version B):
Otherwise, the helper interprets "out" as the tuple "(new_state,
prep_msg)", where "new_state" is its updated preparation state and
"prep_msg" is its next VDAF message.
Paragraph (version A):
The opaque aggregation parameter for the VDAF beging executed.
This value MUST match the same value in the the
"AggregateInitializeReq" message sent in at least one run of the
aggregate sub-protocol.  (See leader-init). and in "CollectReq"
(see collect-init).
Paragraph (version B):
The opaque aggregation parameter for the VDAF being executed.
This value MUST match the same value in the the
"AggregateInitializeReq" message sent in at least one run of the
aggregate sub-protocol.  (See leader-init). and in "CollectReq"
(see collect-init).
Paragraph (version A):
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).
Paragraph (version B):
However, Aggregators are also required to implement several per-
report checks that require retaining a number of data artifacts.  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
alleviate this burden, DAP allows Aggregators to drop this state as
needed, so long as reports are dropped 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).
Paragraph (version A):
The input validation protocol executed by the aggregators prevents
either individual clients or coalitions of clients from
compromising the robustness property.
Paragraph (version A):
If aggregator output satisifes differential privacy dp, then all
records not leaked by malicious clients are still protected.
Paragraph (version B):
The input validation protocol executed by the aggregators prevents
either individual clients or a coalition of clients from
compromising the robustness property.
Paragraph (version B):
If aggregator output satisfies differential privacy dp, then all
records not leaked by malicious clients are still protected.
Paragraph (version A):
Client reports can contain auxiliary information such as source IP,
HTTP user agent or in deployments which use it, client authentication
information, which could be used by aggregators to identify
participating clients or permit some attacks on robustness.  This
auxiliary information could be removed by having clients submit
reports to an anonymizing proxy server which would then use Oblivous
HTTP I-D.thomson-http-oblivious to forward inputs to the DAP leader,
without requiring any server participating in DAP to be aware of
whatever client authentication or attestation scheme is in use.
Paragraph (version B):
Client reports can contain auxiliary information such as source IP,
HTTP user agent or in deployments which use it, client authentication
information, which could be used by aggregators to identify
participating clients or permit some attacks on robustness.  This
auxiliary information could be removed by having clients submit
reports to an anonymizing proxy server which would then use Oblivious
HTTP I-D.thomson-http-oblivious to forward inputs to the DAP leader,
without requiring any server participating in DAP to be aware of
whatever client authentication or attestation scheme is in use.