Draft: draft-ietf-ppm-dap

Commentary: Resubmission of in order to resolve conflicts . Originally authored by I did a pass through the document to s7 . All of these are intended to be editorial even though some of them affect the presentation syntax .
Paragraph (version A):
The specific properties attested to in the proof vary depending on
the measurement being taken.  For instance, if we want to measure the
time the user took performing a given task the proof might
demonstrate that the value reported was within a certain range (e.g.,
0-60 seconds).  By contrast, if we wanted to report which of a set of
N options the user select, the report might contain N integers and
the proof would demonstrate that N-1 were 0 and the other was 1.
Paragraph (version B):
The specific properties attested to in the proof vary depending on
the measurement being taken.  For instance, to measure the time the
user took performing a given task the proof might demonstrate that
the value reported was within a certain range (e.g., 0-60 seconds).
By contrast, to report which of a set of N options the user select,
the report might contain N integers and the proof would demonstrate
that N-1 were 0 and the other was 1.
Paragraph (version A):
In the remainder of this document, we use the tokens in the table
above to refer to error types, rather than the full URNs.  For
example, an "error of type 'unrecognizedMessage'" refers to an error
document with "type" value
"urn:ietf:params:ppm:dap:error:unrecognizedMessage".
Paragraph (version B):
In the remainder of this document, the tokens in the table above are
used to refer to error types, rather than the full URNs.  For
example, an "error of type 'unrecognizedMessage'" refers to an error
document with "type" value
"urn:ietf:params:ppm:dap:error:unrecognizedMessage".
Paragraph (version A):
We start with some basic type definitions used in other messages.
Paragraph (version A):
The first query type, "time-interval", is designed to support
applications in which reports are collected over a long period of
time.  The Collector specifies a "batch interval" that determines the
time range for reports included in the batch: For each report in the
batch, the time at which that report was generated (see upload-flow)
must fall within the batch interval specified by the Collector.
Paragraph (version A):
Typically the Collector issues queries for which the batch intervals
are continuous, monotonically increasing, and have the same duration.
For example, the sequence of batch intervals.  For example, the
sequence of batch intervals "(1659544000, 1000)", "(1659545000,
1000)", "(1659545000, 1000)", "(1659546000, 1000)" satisfies these
conditions.  (The first element of the pair denotes the start of the
batch interval and the second denotes the duration.)  Of course,
there are cases in which Collector may need to issue queries out-of-
order.  For example, a previous batch might need to be queried again
with a different aggregation parameter (e.g, for Poplar1).  In
addition, the Collector may need to vary the duration to adjust to
changing report upload rates.
Paragraph (version B):
The first query type, "time-interval", is designed to support
applications in which reports are collected over a long period of
time.  The Collector specifies a "batch interval" that determines the
time range for reports included in the batch.  For each report in the
batch, the time at which that report was generated (see upload-flow)
must fall within the batch interval specified by the Collector.
Paragraph (version B):
Typically the Collector issues queries for which the batch intervals
are continuous, monotonically increasing, and have the same duration.
For example, the sequence of batch intervals "(1659544000, 1000)",
"(1659545000, 1000)", "(1659545000, 1000)", "(1659546000, 1000)"
satisfies these conditions.  (The first element of the pair denotes
the start of the batch interval and the second denotes the duration.)
Of course, there are cases in which Collector may need to issue
queries out-of-order.  For example, a previous batch might need to be
queried again with a different aggregation parameter (e.g, for
Poplar1).  In addition, the Collector may need to vary the duration
to adjust to changing report upload rates.
Paragraph (version A):
An aggregator is free to use different HPKE configurations for each
task with which it's configured.  If the task ID is missing from a
client's request, the aggregator MAY abort with an error of type
"missingTaskID", in which case the client SHOULD retry the request
with a well-formed task ID included.
Paragraph (version B):
An aggregator is free to use different HPKE configurations for each
task with which it is configured.  If the task ID is missing from a
client's request, the aggregator MAY abort with an error of type
"missingTaskID", in which case the client SHOULD retry the request
with a well-formed task ID included.
Paragraph (version A):
the HPKE configuration specifies a KEM, KDF, or AEAD algorithm the
client doesn't recognize.
Paragraph (version B):
the HPKE configuration specifies a KEM, KDF, or AEAD algorithm the
client does not recognize.
Paragraph (version A):
HTTPS provides confidentiality between the DAP client and the leader,
but this is not sufficient since the helper's report shares are
relayed through the leader.  Confidentiality of report shares is
achieved by encrypting each report share to a public key held by the
respective aggregator.  Clients fetch the public keys from each
aggregator over HTTPS, allowing them to authenticate the server.
Paragraph (version A):
Aggregators MAY require clients to authenticate when uploading
reports.  This is an effective mitigation against Sybil attacks in
deployments where it is practical for each client to have an identity
provisioned (e.g., a user logged into an online service or a hardware
device programmed with an identity).  If it is used, client
authentication MUST use a scheme that meets the requirements in
request-authentication.
Paragraph (version B):
HTTPS provides confidentiality between the DAP client and the leader,
but this is not sufficient since the helper's report shares are
relayed through the leader.  Confidentiality of report shares is
achieved by encrypting each report share to a public key held by the
respective aggregator using HPKE.  Clients fetch the public keys from
each aggregator over HTTPS, allowing them to authenticate the server.
Paragraph (version B):
Aggregators MAY require clients to authenticate when uploading
reports.  This is an effective mitigation against Sybil Dou02 attacks
in deployments where it is practical for each client to have an
identity provisioned (e.g., a user logged into an online service or a
hardware device programmed with an identity).  If it is used, client
authentication MUST use a scheme that meets the requirements in
request-authentication.
Paragraph (version A):
where [leader_outbound, helper_outbound] is a vector of two elements.
If either of these operations fails, then the leader marks the report
as invalid.  Otherwise it interprets "out" as follows.  If this is
the last round of the VDAF, then "out" is the aggregator's output
share, in which case the aggregator finishes and stores its output
share for further processing as described in collect-flow.
Otherwise, "out" is the pair "(new_state, prep_msg)", where
"new_state" is its updated state and "prep_msg" is its next VDAF
message (which will be "leader_outbound" in the next round of
continuation).  For the latter case, the helper sets "prep_state" to
"new_state".
Paragraph (version B):
where [leader_outbound, helper_outbound] is a vector of two elements.
If either of these operations fails, then the leader marks the report
as invalid.  Otherwise it interprets "out" as follows: If this is the
last round of the VDAF, then "out" is the aggregator's output share,
in which case the aggregator finishes and stores its output share for
further processing as described in collect-flow.  Otherwise, "out" is
the pair "(new_state, prep_msg)", where "new_state" is its updated
state and "prep_msg" is its next VDAF message (which will be
"leader_outbound" in the next round of continuation).  For the latter
case, the helper sets "prep_state" to "new_state".
Paragraph (version A):
To carry out this step, for each PrepareStep in
AggregateContinueReq.prepare_shares received from the leader, the
helper performs the following check to determine if the report share
should continue being prepared.
Paragraph (version A):
where "inbound" is the previous VDAF preapre message sent by the
leader and "prep_state" is the helper's current preparation state.
If this operation fails, then the helper fails with error "vdaf-prep-
error".  Otherwise, it interprets "out" as follows.  If this is the
last round of VDAF preparation phase, then "out" is the helper's
output share, in which case the helper stores the output share for
future collection.  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):
If this is the last round of VDAF preparation phase, then "out" is
the helper's output share, in which case the helper stores the
output share for future collection.
Paragraph (version B):
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 A):
The leader obtains each helper's encrypted aggregate share in order
to respond to the collector's collect response.  To do this, the
leader first computes a checksum over the set of output shares
included in the batch.  The checksum is computed by taking the SHA256
hash of each nonce from the client reports included in the
aggregation, then combining the hash values with a bitwise-XOR
operation.
Paragraph (version B):
The leader obtains each helper's encrypted aggregate share in order
to respond to the collector's collect response.  To do this, the
leader first computes a checksum over the set of output shares
included in the batch.  The checksum is computed by taking the SHA256
SHS hash of each nonce from the client reports included in the
aggregation, then combining the hash values with a bitwise-XOR
operation.
Paragraph (version A):
Next, it computes a checksum based on the reports that satisfy the
query, and checks that the "report_count" and "checksum" included in
the request match its computed values.  If not, then it MUST abort
with error "batchMismatch".
Paragraph (version B):
Next, it computes a checksum based on the reports that satisfy the
query, and checks that the "report_count" and "checksum" included in
the request match its computed values.  If not, then it MUST abort
with an error of type "batchMismatch".
Paragraph (version A):
HTTPS provides confidentiality and authenticates the leader to the
collector.  Additionally, the leader encrypts its aggregate share to
a public key held by the collector.
Paragraph (version B):
HTTPS provides confidentiality and authenticates the leader to the
collector.  Additionally, the leader encrypts its aggregate share to
a public key held by the collector using HPKE.
Paragraph (version A):
Confidentiality is achieved by having the helper encrypt its
aggregate share to a public key held by the collector.
Paragraph (version B):
Confidentiality is achieved by having the helper encrypt its
aggregate share to a public key held by the collector using HPKE.
Paragraph (version A):
These are both attacks on robustness, which we already assume to hold
only if both aggregators are honest, which puts these malicious-
leader attacks out of scope (see sec-considerations.
Paragraph (version B):
These are attacks on robustness, which we already assume to hold only
if both aggregators are honest, which puts these malicious-leader
attacks out of scope (see sec-considerations).
Paragraph (version A):
First the Aggregator checks that the batch respects any "boundaries"
determined by the query type.  These are described in the subsections
below.  If the boundary check fails, then the Aggregator MUST abort
with error "batchInvalid".
Paragraph (version A):
Next, the Aggregator checks that batch contains a valid number of
reports, as determined by the query type.  If the size check fails,
then the Aggregator MUST abort with error "invalidBatchSize".
Paragraph (version A):
Next, the Aggregator checks that the batch has not been aggregated
too many times.  This is determined by the maximum batch lifetime,
"max_batch_lifetime".  Unless the query has been issued less than
"max_batch_lifetime" times, the Aggregator MUST abort with error
"batchLifetimeExceeded".
Paragraph (version A):
Finally, the Aggregator checks that the batch does not contain a
report that was included in any previous batch.  If this batch
overlap check fails, then the Aggregator MUST abort with error
"batchOverlap".  For time-interval tasks, it is sufficient (but not
necessary) to check that the batch interval does not overlap with the
batch interval of any previous query.  If this batch interval check
fails, then the Aggregator MAY abort with error "batchOverlap".
Paragraph (version B):
First the Aggregator checks that the batch respects any "boundaries"
determined by the query type.  These are described in the subsections
below.  If the boundary check fails, then the Aggregator MUST abort
with an error of type "batchInvalid".
Paragraph (version B):
Next, the Aggregator checks that batch contains a valid number of
reports, as determined by the query type.  If the size check fails,
then the Aggregator MUST abort with error of type "invalidBatchSize".
Paragraph (version B):
Next, the Aggregator checks that the batch has not been aggregated
too many times.  This is determined by the maximum batch lifetime,
"max_batch_lifetime".  Unless the query has been issued less than
"max_batch_lifetime" times, the Aggregator MUST abort with error of
type "batchLifetimeExceeded".
Paragraph (version B):
Finally, the Aggregator checks that the batch does not contain a
report that was included in any previous batch.  If this batch
overlap check fails, then the Aggregator MUST abort with error of
type "batchOverlap".  For time-interval tasks, it is sufficient (but
not necessary) to check that the batch interval does not overlap with
the batch interval of any previous query.  If this batch interval
check fails, then the Aggregator MAY abort with error of type
"batchOverlap".
Paragraph (version B):
Implement and store state for the form of inter- and intra-batch
replay mitigation in anti-replay.