Change:
7.7. <ins> The verification key for a task SHOULD be chosen before any reports are generated.  It SHOULD be fixed for the lifetime of the task and not be rotated.  One way to ensure this is to include the verification key in a derivation of the task ID. This consideration comes from current security analysis for existing VDAFs.  For example, to ensure that the security proofs for Prio3 hold, the verification key MUST be chosen independently of the generated reports.  This can be achieved as recommended above. 7.8. </ins> Prio deployments should ensure that aggregators do not have common dependencies that would enable a single vendor to reassemble inputs. For example, if all participating aggregators stored unencrypted

Discussion:
The analysis posted describes the security consideration for DAP: Assuming we agree this is an issue that needs to be addressed, what should we do about it?
One suggestion, due to NAME is to derive the task ID from the verification key by applying a one-way function. That way there is no possibility of the task ID being picked before the key. Being a bit more careful, we might use HKDF to derive both strings from a shared secret. Perhaps something like:
Should this be an ? I think we agreed that using a ROish derivation function including the client nonce would be sufficient, right?
Actually I intended "and" :) This security consideration has to do with privacy. For Prio3, we need the "query randomness" generated by the Aggregators to be "fresh". (By "fresh" I mean it needs to be random and the adversary should not be able to influence this value.) Our security model for privacy allows the adversary to pick the verifykey: In order to ensure freshness of the query randomness used for a given report, it is sufficient to (i) pick verifykey prior to generating the report and (ii) choose a random nonce. If we didn't have (i), then attacker controls the query randomness by picking a favorable verify_key to prepare the report with: if we didn't have (ii), then query randomness is predictable to the attacker.
But if the query randomness depends on the report nonce (as in ) an attacker who controls verifkey can not pick a favorable verifkey because of the RO properties. Right?
Good question. So the attacker knows and , and it can pick before the honest aggregator computes . Thus, it can query the RO with different s until it finds one for which the is "favorable". Does this make sense? In other words, "queryrand" is not uniformly distributed, even though it was output by the RO! Its distribution is biased towards whatever property is favorable to the attacker. For instance, if for some reason is favorable if its first bit is , then the attacker can easily arrange things so that the honest Aggregator computes that begins with .
If this is a problem, the problem also exists with 50% probability when using true randomness, so this shouldn't be an issue.
I'm just trying to give an example of how the attacker can bias the randomness.

With more random oracle queries, it can fix the first 2 bits, 3 bits, ..., N bits, etc. It doesn't really matter. The point is: This possibility of this attack prevents a reduction to honest-verifier ZK of the FLP. (This is a standard assumption and is what is proven for the FLP we use in Prio3: See .) To avoid this, we need all inputs to the random oracle, including , to be fixed before honest Aggregators compute . Hello CFRG, This message is to share with you all some recent security analysis of draft-irtf-cfrg-vdaf-03 [1]. This is joint work with the draft editors (Phillipp and myself), Hannah Davis (UCSD), and Mike Rosulek (OSU): URL The primary goal of this paper is to formulate a provable security framework for studying candidate VDAFs. We give two definitions that formalize "privacy" and, separately, "robustness", as described in [1, Section 9]. We study two schemes in our paper: Prio3 [1, Section 7]; and a variant of Poplar1 [1, Section 8] that improves round complexity. We call this variant "Doplar". (More on this below.) Apart from some minor changes to the draft, the most important takeaways are additional security considerations for VDAF users, e.g., DAP [2], will need to attend to. I'll start with a quick overview of the security model in (1). I'll then describe how we think this model translates into security considerations in (2). In (3) I will enumerate the changes to algorithms in the draft that we are making in light of the results in this paper. I'll end in (4) with a couple of random observations. We (the authors of the paper) welcome and appreciate any feedback folks might have on the paper. We're also happy to answer questions, here or in GH issues :) On behalf of the authors: Thanks for reading! Chris P. (1) Security model In the following, we refer to the set of input shares generated by a Client (via the algorithm) as the Client's "report". In our security definitions, each report has an associated "nonce" generated by the Client as well.

(1.1) Privacy The main goal for VDAFs is to ensure that, as long as some fraction of Aggregators is honest, the attacker learns nothing about the Clients' measurements beyond the aggregate result. Our privacy game (Figure 4 in the paper) gives the attacker complete control over VDAF execution, except for transmission of the input shares from honest Clients to honest Aggregators. The game models a kind of "chosen-batch attack" (analogous to a "chosen-plaintext attack" for encryption) where the attacker provides each Client with a pair of measurements, and the game picks which one is processed based on a coin toss at the start of the game. The adversary wins if, at the end of the game, it guesses correctly which batch of measurements was processed. We say the VDAF is private if no reasonable adversary wins with probability better than 1/2 (Definition 3). There are a couple features of our security game that are worth calling out. (1.1.1) First, the attacker gets to pick the VDAF verification key used for processing the reports. This models settings in which the key is generated by one (possibly malicious) Aggregator and distributed to the others. (For instance, in DAP we would like it if we could have the Leader pick this value unilaterally: See issue URL) This turns out to be fine, but we need to be somewhat careful here. The current privacy proof for Prio3 (Theorem 2) assumes the underlying FLP system ("Fully Linear Proof"; see [1, Section 7.1]) is "honest-verifier" zero-knowledge. An honest verifier picks its challenge at random, so in order to push through the reduction to VDAF privacy, we would need to emulate this random challenge in Prio3. The challenge (called the "query randomness" in the spec) is derived from the verification key and the nonce picked by the Client. When modeling the function used to derive the challenge as a random oracle, it is sufficient to ensure that (i) the VDAF verification is fixed prior to the report being generated and (ii) the nonce is chosen at random by the Client. Remark: Other restrictions on the model are possible.

For instance, it may be sufficient to ensure, somehow, that the verification key is chosen randomly via some secure coin flipping protocol. (See discussion in URL) However, this would shift more complexity to DAP. Requiring (i) and (ii) seemed to be the minimally invasive change. (1.1.2) Our model involves a notion of "allowed initial states''. The "initial state" basically means "aggregation parameter", e.g., a set of candidate prefixes for Poplar1. In our analysis of Doplar (Theorem 4) we found it necessary to restrict the attacker to aggregating a given report at most one time per level of the IDPF tree. Otherwise, there are subtle attacks that arise when the validity proof for a given level is allowed to be reused. Remark: Although we did not study Poplar1 in detail, we believe there are similar attacks if the "authenticator value" for a given level of the IDPF tree is reused. Thus we have to restrict the initial states in the same way. (1.2) Robustness Our secondary goal for VDAFs is that, if all Aggregators execute the protocol correctly, then the Collector correctly computes the aggregate result of reports uploaded by honest Clients. (Reports generated by malicious Clients are filtered out during preparation.) Here we consider the attacker to be a cohort of malicious Clients who can eavesdrop on the preparation phase (i.e., it gets to see the messages exchanged by the Aggregators). The attacker's goal is to cause an Aggregator to accept a share of an invalid report. (Validity is defined by the VDAF itself; see "refinement consistency" in Section 3.1.) The game requires the VDAF verification key is unknown to the attacker. It also requires that nonces are non-repeating. We say that the VDAF is robust if the probability of the attacker winning this is small. Remark: There are important differences between the threat model for privacy and robustness.

(One allows the attacker to control aggregators, while the other does not; one allows the attacker to control the network, while the other does not; one allows the verification key to be picked by the attacker, while the other requires the key to be random; one requires the nonce to be random, while the nonce to be simply non-repeating.) It's worthwhile asking whether both properties can be achieved under the same threat model. However, it is not possible for the current crop of VDAFs. (2) Security considerations Based on the security model and analysis of Prio3 and Doplar (which is related to Poplar1; see below), we have the following recommendations for additional security considerations. (2.1) Verification key requirements Some care is required in choosing the VDAF verification key. The Aggregators may use any strategy they wish to exchange this key, but the application MUST ensure that the key that is picked independently of the reports. For DAP in particular, this means it is safe for the Leader to pick the key and distribute it, but the Aggregators need to "commit" to the verification key used for a given task and use the same key for the duration of the task. (Rotation requires rolling the task configuration.) Unfortunately, this contradicts a current recommendation. From [1, Section 9]: "It is also possible to consider a stronger form of robustness, where the attacker also controls a subset of Aggregators (see [BBCGGI19], Section ). To satisfy this stronger notion of robustness, it is necessary to prevent the attacker from sharing the verification key with the Clients. It is therefore RECOMMENDED that the Aggregators generate verifykey only after a set of Client inputs has been collected for verification, and re-generate them for each such set of inputs." Note that preventing leakage of the verification key to the clients is necessary for robustness in this stronger threat model, but not sufficient. Thus this recommendation boils down to defense-in-depth for robustness. In our opinion, privacy takes precedence here. (2.1) Nonce requirements Clients MUST choose the report nonce at random. This ensures the nonce is unpredictable to a privacy attacker; and it reduces the chance of collisions, which is required for robustness.

(2.2) Requirements for report processing Poplar1: Applications MUST ensure that reports are aggregated at most once per-level. Repeated usage of the authenticator at a given level may lead to subtle attacks on privacy. In particular, the current "maxbatchquery_count" mechanism of DAP [2, Section 4.5.6] is not sufficient. Prio3: Applications SHOULD ensure that each report is processed at most once. It's probably safe to allow re-processing, but (1) this is not captured in our model; (2) this gets hairy in terms of differential privacy (see issue URL); and (3) there doesn't seem to be a good reason to allow this. (It is explicitly disallowed in DAP.) (2.3) Security requirements for the PRG The object defined in [1, Section 6.2] is used to map a seed to a pseudorandom value of a suitable type, e.g., another seed, or a vector of field elements. Our security analysis models each such mapping as an independent, random oracle. As such, MUST be instantiated with a primitive that is well-suited for this purpose, like SHA-3. Relatedly, inputs to random oracles need to be "decodable". Essentially this is because the current proofs use an RO extractor for proving robustness. (3) Changes to Prio3 and Poplar1 To prove Prio3 secure in our model, we needed to make some minor adjustments to the scheme. We also have some suggestions for Poplar1 based on our analysis of Doplar, which is quite similar. We summarize our suggestions below. (Note that some of these changes have already been merged.) (3.1) Prio3: Improve domain separation of calls to . (Similarly for Poplar1.) PR: URL (3.2) Prio3: Add nonce to transcript for joint randomness derivation. This leads to an improved robustness bound. Issue: URL Closed by PR: URL (3.3) Replace with something that is more suitable for instantiating a random oracle, like SHA-3. Issue: URL Candidate PR (uses cSHAKE128): URL (3.4) Specify the nonce length.

Right now the nonce is allowed to be variable length, but since privacy requires this to be randomly generated, and not all nonce lengths are safe, it makes sense to be more prescriptive here. This is also useful for making it easier to decode RO queries (see (2.3)). Issue: URL (4) Other things (4.1) What is this "Doplar" thing and what should we do with it? Doplar is like Poplar1 in that it solves the same use case (heavy hitters). It is different in that, instead of two rounds of communication for the preparation phase, only one round is required. The cost of this improvement is an increase in overall communication overhead (i.e., there are fewer messages, but they are larger in size). See Section 5.3 of the paper for a comparison. Before considering replacing Poplar1, it is worth investigating whether the communication overhead can be reduced. We are optimistic that it can be. In any case, the draft editors think that it would be best to keep Poplar1 in the current draft; if we were to specify Doplar, it would go in a new document. (4.2) Consider specializing VDAF syntax to one round preparation Given that heavy hitters is achievable with one-round preparation, we might consider specializing the syntax in [1, Section 5.2] to one round instead of many. This would make specs like DAP [2] vastly simpler. (DAP is currently suffering from a degree of complexity resulting from generality.) Acknowledgements Thanks to Simon Friedberger and Tim Geoghegan for illuminating conversations about security considerations. References [1] VDAF draft: URL [2] DAP draft: URL