Draft: draft-ietf-ppm-dap

Commentary: We might want to consider renaming to something based on what it 's actually doing , which is helping with replay protection . Maybe ? 
 ~Wait , what ? Replay is enforced on the basis of Nonce in its entirety , which currently consists of a ( 1 ) timestamp and ( 2 ) a random value.~ Chatted to clear this up in Slack 
 Not sure if DAP enforces precision of : But with fine - grained timestamp , it is easier for attacker to associate a report with the user sent that report . For example , if timestamp is accurate to second , and leader is compromised , attacker can compare users that uploaded at a given second ( perhaps from a routing server ) and reports ' timestamp , then figure out if a particular user has contributed to a task . With a coarse - grained timestamp , however , we can minimise this threat with a secure routing server . Anti - replay can still be satisfied with the UUID part of Nonce . 
 This is a valid concern . One reasonable change would be to modify the report timestamp to align with the batch window start ( minbatchduration ) , and then bump the size of the nonce to offset the increase change of collisions . Specifically , this would mean we update the Nonce like so : would this work ? thoughts ? 
 I think this should work . 
 Great ! I 'll prep a PR . 
 I would add the can also be of any length , so aligning  with it will make it coarse - grained for use cases where is large , say in hours , but wo n't be as effective for very small , but I think that should probably be addressed separately . 
 I 'm happy with this change , though 16 bytes will be sufficient since clients are supposed to choose this at random . ( Note that we chose 32 bytes for the various " IDs " ( i.e. , task ID , aggregation - job ID ) because we anticipated some deployments using a hash of something as the ID . 
 Yep 
 We currently have an open issue for tracking the consensus protocol needed for this system to work . In working through this text , we should make note of what sort of synchronization we assume between different participants of the system . 
 In the 3/17 design call we agreed that for purposes of the design doc and probably the initial deployments of Prio , we would assume that shared parameters ( e.g. , arithmetic circuits , primes , aggregation identifiers ) would be exchanged between all parties ( i.e. , clients , aggregators , collector , leader ) before the start of the protocol over some unspecified secure channel . However , eventually , it should be possible for a client that wishes to use Prio to programmatically : discover participating servers ( i.e. , a directory of aggregators ) discover the capabilities of participating servers ( i.e. , what algorithms do they support for secret sharing or validity proofs or aggregations ? What optional protocol features do they support ? ) configure a Prio aggregation ( i.e. , select some number of aggregation servers , getting a unique handle , configuring field size , etc . ) 
 One thing that 's still TBD is how to choose the joint randomness . It could be as simple as having the leader choose a seed for a PRG and distributing it to the aggregators over secure channels . It could be as complicated as querying at some point after the shares are received by the aggregators . 
 To close the loop on this issue : the PDA parameters are distributed to all entities out - of - band . 
   and I hashed this out .  convinced me that as written , the rounding of is optional for the client , and aggregators do n't need to do anything special to handle unrounded nonces : if that happens aggregators can still use the unrounded nonce to correctly identify a bucket to put the report in , so this is something that a client should do in order to improve privacy , but nothing breaks if they fail to . With that in mind , I do n't think we need new text to explain what aggregators should do with nonces that are n't rounded correctly , nor does the new text for the client need a MUST .
Paragraph (version A):
To generate the report, the client begins by initializing the report
nonce.  Specifically, the client first sets "Nonce.rand" to 16 random
bytes output from a cryptographically secure random number generator.
It then sets "Nonce.time" to the current UNIX time rounded down to
the nearest multiple of "min_batch_duration".  This truncation is
done to ensure that the report's timestamp cannot be used to link the
report back to the originating client.
Paragraph (version B):
To generate the report, the client begins by initializing the report
nonce.  Specifically, the client first sets "Nonce.rand" to 16 random
bytes output from a cryptographically secure random number generator.
It then sets "Nonce.time" to the number of seconds elapsed since the
start of the UNIX epoch, rounded down to the nearest multiple of
"min_batch_duration".  This truncation is done to ensure that the
report's timestamp cannot be used to link the report back to the
originating client.