Original text:
These parameters are distributed out of band to the clients and to the aggregators.  They are distributed by the collecting entity in <del> some authenticated form.  The reason being, that the collecting entity (e.g. a company or group of companies providing some client software it wants to collect measurements from) is in a privileged position anyway, because it could simply chose not to use DAP at all. Each task is identified by a unique 32-byte ID which is used to refer to it in protocol messages. </del>  During the duration of the measurement, each client records its own value(s), packages them up into a report, and sends them to the

Reviewer comments:
Proposal for URL
as part of task parameters is distributed out of band by aggregators. At the moment there's no protocol level support to guarantee is not maliciously reduced by a dishonest leader. For use cases that work with central differential privacy, the is chosen based on an epsilon-dp guarantee over a certain batch. A dishonest leader can send a smaller to helper to break a strong dp guarantee. One possible solution is to include parameters like (and other privacy parameters, for eg. epsilons in differential privacy) in , which will become part of AAD therefore avoid tempering, and enforcing aggregators to check the out-of-band matches the ones included in every field for the same task. Aggregator can also implement a one-off calculation on the task parameters to verify the is reasonable with other provided privacy parameters. For example, given a local differential privacy epsilon e0, target central differential privacy epsilon ec, and a minbatchsize N, we can calculate whether ec can be achieved by aggregating e0 over N reports, by using various shuffling amplification analysis.
is distributed out-of-band, which means that the helper and leader are considered to both have the value configured separately (i.e. without a chance for one of the aggregators modify the value that is configured for the other aggregator). is also evaluated separately and independently by each aggregator for each collect operation. The leader's check is specified in & the helper's check is specified in . (In both cases, the relevant section refers to the section which specifies the check directly.) Given the above, I believe a malicious leader cannot reduce , either at time of task initialization or at time of collection. (A malicious leader can certainly skip its own check, but as long as the helper does not collude, a small batch will still be caught by the helper's check.) This is an interesting idea & worthy of consideration IMO -- AFAIK, the DAP spec currently does not speak to what values of are reasonable.
I think the problem is DAP doesn't specify how task parameters are distributed out-of-band. If the task parameters is sent to helper from a malicious leader before task initialisation, then the helper would check against a wrong later. Having said that, my above suggestion of checking against a in AAD also assumes client have the right task parameters. On the other hand, I see there is an open issue in : These DP parameters will face the same problem: how do we guarantee they are configured honestly. I agree we should consider adding calculation from epsilon-dp parameters. There are well researched paper about calculating based on local DP from each client and a desired central DP on the batch. This may need to be VDAF specific though.
Regarding the values of , there is an explicit statement in "": I think there also used to be a somewhat obvious statement that if is 1 there is no privacy but I cannot find it anymore. I assume specification is avoided because there might be corner cases where low values make sense, e.g. some tasks might have a batch size of 2 because plausible deniability is enough. I would also like to see some guidance/examples on this but probably in the VDAF spec.
As NAME points out, the DAP draft doesn't try to define a set of configuration parameters that are sufficient for all deployments. Indeed, this is something we expect to be deployment specific, particularly when DP is desired. NAME it sounds like what you're after here is a means of opting out of a task if its configuration does not provide a sufficient level of privacy (for some definition of "privacy"). I think some part of this mechanism is inherently deployment-specific, but it might be useful to specify some protocol logic that is likely to be common to multiple deployments. One question is whether this mechanism should be implemented during the "online" phase of the protocol, as you suggest (i.e., during upload, aggregation, or collection) or "offline" at configuration time. Offline seems preferable to me, given that this is always treated as a fatal error. However since we haven't yet specified how tasks are configured, it's not clear that we can define any behavior here. Suppose each Aggregator implemented an endpoint, e.g., , to which the Collector posted task configurations. We could allow the aggregator to "abort" this request with a specific error, e.g., . Would this be sufficient?
I don't think that it makes sense to have the set by the client and covered by the HPKE AAD. There's no way for the client to verify or enforce that either aggregator actually honored the value covered by the report AAD, so I don't think it would mitigate any of the currently possible attacks. Further, I believe that in order to undermine the privacy parameter, you need both/all aggregators to collude -- it doesn't do leader any good to emit aggregate shares over a single report unless helper computes an aggregate share over that same report. If you admit colluding aggregators, then you're outside of DAP's threat model: if they're already colluding, then they might as well just send each other decrypted input shares. I think the same applies to aggregators using the wrong epsilon on an aggregate share -- it won't help unless both aggregators subvert the protocol together. >Suppose each Aggregator implemented an endpoint, e.g., , to which the Collector posted task configurations. We could allow the aggregator to "abort" this request with a specific error, e.g., . Would this be sufficient? I don't think we can specify an endpoint in DAP without opening the can of worms of bringing task parameter negotiation into the scope of the protocol.
Yes. I agree complete mitigation will likely be deployment-specific. NAME that's only the case after task initialization. But the parameters can be corrupted at task initialization stage, I imagine it's very common for the leader's organisation to drive the task, if helpers just receive task parameters from leader, then they are unable to verify if the parameters from leader can guarantee any privacy for the task.
This issue essentially captures the transparency and parameter enforcement part of issue URL
NAME I think the threat model here necessarily assumes that at least one aggregator is honest. I think you're right that if both were dishonest, including in Report has no benefit. But if at least one is honest, then doesn't the client have assurance that at least one aggregator checked it and acted accordingly?
I think there are three issues being conflated here: A malicious leader reducing which, it was assumed that leader, helpers and collector agreed on this value out of band so this should be impossible. Aggregators actually enforcing (what the title says) which they always had to do. Clients actually knowing what will be enforced which is the transparency part. I think 3. is a great idea, 1. should probably be discussed in and 2. is a misunderstanding.

Revised text:
These parameters are distributed out of band to the clients and to the aggregators.  They are distributed by the collecting entity in  <ins> some authenticated form.  Each task is identified by a unique 32-byte ID which is used to refer to it in protocol messages. </ins> During the duration of the measurement, each client records its own value(s), packages them up into a report, and sends them to the