Draft: draft-ppm-protocol

Commentary: 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 : 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 . 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 do n't think this caveat is bad enough to be worthy of specifying grace_window with a MUST , I only note it for posterity . 
 I wo n'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 timg 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 can not 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 ( thanks for the link )
Paragraph (version A):
The leader is required to issue aggregate requests in order, but
reports are likely to arrive out-of-order.  The leader SHOULD buffer
reports for a time period proportional to the batch window before
issuing the first aggregate request.  Failure to do so will result in
out-of-order reports being dropped by the helper.
Paragraph (version B):
The leader is required to issue aggregate requests in order, but
reports are likely to arrive out-of-order.  The leader SHOULD store
reports for a time period proportional to the batch window before
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.
Paragraph (version A):
Using a report multiple times within a single batch, or using the
same report in multiple batches, is considered a privacy violation.
To prevent such replay attacks, this specification defines a total
ordering on reports that aggregators can use to ensure that reports
are aggregated once.
Paragraph (version B):
Using a client-provided report multiple times within a single batch,
or using the same report in multiple batches, may allow a server to
learn information about the client's measurement, violating the
privacy property of PPM.  To prevent such replay attacks, this
specification defines a total ordering on reports that aggregators
can use to ensure that reports are aggregated once.