Draft: draft-ietf-ppm-dap

Commentary: 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 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 did n't have ( i ) , then attacker controls the query randomness by picking a favorable verify_key to prepare the report with : if we did n'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 should n'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 does n'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 .
Paragraph (version B):
"vdaf_verify_key": The VDAF verification key shared by the
aggregators.  This key is used in the aggregation sub-protocol
(aggregate-flow).  The security requirements are described in
verification-key.
Paragraph (version B):
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.
Paragraph (version B):
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.