Change:
4.3.1.1. The leader is required to issue aggregate requests in order, but <del> reports are likely to arrive out-of-order.  The leader SHOULD buffer </del> <ins> reports are likely to arrive out-of-order.  The leader SHOULD store </ins> reports for a time period proportional to the batch window before <del> issuing the first aggregate request.  Failure to do so will result in out-of-order reports being dropped by the helper. </del> <ins> including them in an aggregate request.  Failure to do so may result in out-of-order reports being dropped by the helper.  The leader MUST NOT accept reports whose timestamps are in the future.  Implementors MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. </ins> 4.3.1.2.

Discussion:
As previously written, the timing of report aggregations would allow aggregation of reports with timestamps far into the future, which would allow a single client reporting a timestamp of INT_MAX to DOS the aggregation system due to the way timestamps are used in the anti-replay mechanism. Given the severity of not following this portion of the specification, I upgrade the SHOULD to a MUST as well.
At a high level, there are two ways for this to work: The leader and the helper agree precisely on which reports are acceptable, in which case (a) they need to have agreement on how much slack there is and (b) have precisely synchronized clocks. If the leader sends the helper an invalid share, then this can be a fatal error. The leader and the helper. In this case, they do not need to have agreement on slack or have synchronized clocks, but we then need to deal with the situation in which some shares are unacceptable. This requires a way for the helper to report that and then to know how the leader handles that.
I took another look at the spec and I think we can actually get away without any new agreed-upon parameters, nor synchronized clocks; nor is there a requirement for (new) agreement on shares being unacceptable. (Sorry, I should have caught this during the discussion yesterday.) With the changes in this PR, the leader now needs to know two new parameters: (a) how long into the past to keep reports before including them in an aggregate request, (b) how far into the future a client-provided timestamp can be. The leader uses these parameters to decide, respectively, (a) which client reports to include in a given aggregate request, and (b) which client reports to drop at time of reception. It is capable of performing both of these functions on its own, without need for communication/coordination with the helper. The helper's function for this part of the protocol is to receive aggregate requests, perform the existing anti-replay mechanism (based on ordering of ) to avoid the leader being able to replay reports, then do whatever aggregation is necessary based on the VDAF in use.

The helper does not actually need to know the parameters the leader is using to perform client report selection/filtering, nor does it need to have a clock synchronized with the leader (unless the VDAF needs a clock, I suppose the helper does not need a clock at all for the aggregation portion of the protocol!). Malformed aggregation requests, including (by my reading) those that trigger the anti-replay mechanism, . [edit: actually, currently out-of-order reports are silently dropped: "[The helper] then filters out out-of-order sub-requests by ignoring any sub-request that does not follow the previous one (See Section 4.4.2.)"]
There was some discussion of whether we need to accept client reports timestamped in the future during yesterday's meeting. I wanted to circle back on this. First: an implementation can choose not to accept client timestamps that are in the future. The tradeoff is that clients whose clocks have skewed even a small amount of time into the future will no longer be able to provide reports. For that reason, I think implementations should accept reports timestamped into the future, for a time period on the order of "minutes" or "hours" (but perhaps not "days" or "weeks"?). The leader does have to store these reports -- but since the leader already has to store all reports for some time to allow reports to arrive out-of-order, this is not a totally new requirement. The text in the PR suggests accepting reports timestamped into the future up to a "time proportional to the batch window size"; to be honest, I simply copied forward the previous text's suggestion here. Perhaps there is a better suggestion to be made?
Based on last week's discussion, I dropped the behavior from a to a . Please note this now-allowed bad behavior, copied from the commit message: I don't think this caveat is bad enough to be worthy of specifying gracewindow with a MUST, I only note it for posterity.
I won't have time to look at this by noon, so please merge without my approval.
LGTM! I'll merge at noon unless someone adds a review asking for more changes.
I'd like to look first.
Clients in the PPM send a client-generated tuple with their upload requests, and encrypt their reports using a nonce that is derived from this tuple.

[section 4.2.2] The aggregators use the tuple as a unique identifier for an individual report, to enable an "anti-replay" mechanism described in section 4.4.2. The reasoning for this anti-replay mechanism is described as: I argue that this mechanism does not practically stop any of the actors from submitting some arbitrary report multiple times in a single batch (i.e. "ballot-stuffing"): malicious clients can effectively replay any of their reports by re-submitting the report content re-encrypted with a new tuple; malicious servers can effectively pose as a client and perform the described "malicious client" attack themselves. But per discussion with timgNAME the purpose of the anti-replay mechanism is not to stop a malicious client/server from doing arbitrary ballot-stuffing; it is to protect a malicious leader from using the same legitimate client-provided report multiple times, which could enable certain attacks on client privacy. Separately, there is currently nothing in the spec placing any requirements or server validations on the timestamp value. A misconfigured or malicious client could send a "poisoned" report with a timestamp of . As the leader must send reports to the helper ordered by [sections 4.3.1, 4.4.2], once this report was sent to the helper as part of an aggregation request the leader would no longer be able to submit any additional reports (and if it tried, the helper would silently filter them). Separately (again), message deduplication based on a total ordering of message timestamps will lead to messages that are received in a delayed fashion being dropped, since the leader will no longer be able to include them in aggregation requests. (The same effect would be seen if a misconfigured/malicious client sent a message timestamped forward to the end of the current batch; this is very similar to the "poisoned report" issue above, but somewhat more inherent to the ordering-based deduplication mechanism.) Proposals: Update the explanation of the anti-replay mechanism to describe the intended protection more explicitly, i.e. that it covers only replay of messages sent by a client, with replay attempted by the server (I think). Think through and add server validation on the client-submitted timestamp.

For example, we might decide that only reports in the current batch, or a previous batch falling within a "grace window", are allowed. (I am unsure if this would be acceptable for Heavy Hitters or other PPM algorithms that require a more "online" query capability.) Consider switching away from an ordering-based deduplication system entirely, as it depends on ordering information that cannot be reliably provided by the clients & because it will cause delayed messages to be dropped. Whatever replaces the ordering-based deduplication mechanism will likely require more storage than the ordering-based mechanism, but this might be mitigated by bounding what reports can be accepted by a time or window. Consider switching clients from reporting a timestamp to reporting a counter. The current timestamp-based report could be mapped to a batch ID by something like (though using a counter opens up the possibility of other methods of determining the current ). Reports should still be deduplicated by the tuple. (The ordering-based deduplication mechanism would no longer work.)
I like how the linked PR solves this. Before closing this issue, however, we might consider being a bit more prescriptive, along the lines of URL (thanks NAME for the link)