Original text:
The following are some basic type definitions used in other messages: DAP uses the 16 byte "ReportID" as the nonce parameter for the VDAF <del> "measurement_to_input_shares" and "prep_init" methods (see VDAF. </del>  Thus for a VDAF to be compatible with DAP, it MUST specify a "NONCE_SIZE" of 16 bytes.

Reviewer comments:
Catches us up with recent VDAF changes ([1], [2], [3]). We also require that VDAFs used in DAP have . [1]: URL [2]: URL [3]: URL
In the upcoming VDAF-04, . The intention is that clients will use the report ID they generate as the nonce, corresponding to . Once VDAF-04 is out, we will need to align DAP's discussion of report construction with it.
I probably missed a discussion elsewhere but why are we adding this?
URL explains why VDAF changed to take a random nonce during input sharding.
More information here: URL
It seems this didn't make it into vdaf-4. Should we also push it to dap-5 then?
VDAF-04 has the so we're good here.
Ah, okay, I searched from the beginning and it's missing in 4.1. (Which is for DAFs)
Yeah so far we don't see a need for providing a nonce for DAF sharding. 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

Revised text:
The following are some basic type definitions used in other messages: DAP uses the 16 byte "ReportID" as the nonce parameter for the VDAF  <ins> "measurement_to_input_shares" and "prep_init" methods (see VDAF). </ins> Thus for a VDAF to be compatible with DAP, it MUST specify a "NONCE_SIZE" of 16 bytes.