Draft: draft-pda-protocol

Commentary: Cleans up the " Security Considerations " section which had some excessive nesting and adds content to address and 
 Prio v2 incorporates ingestion servers which sit between clients and aggregators . The ingestion servers : verify attestations from a trusted computing base in the client ( i.e. , secure enclave or TrustZone ) , making it harder for malicious clients to submit invalid inputs ; remove any potentially identifying metadata from client reports before forwarding them to aggregators . " allows a client to make multiple requests of a server without the server being able to link those requests to the client or to identify the requests as having come from the same client . " We should see if we can integrate OHTTP into the DPA protocol as an optional extension that achieves the goals of the Prio v2 ingestion servers . 
 I think this issue is orthogonal to the PA protocol spec , but is certainly a useful enhancement for deployments . 
 If I am not mistaken , the current design would actually allow a malicious leader to learn single client contributions , by only sending that specific data to the aggregator , reporting that the proof is valid , ask the aggregator to " sum " the single element and return the answer . While the current design is motivated by different types of constraints ( soft deadlines / privacy threshold defined by a minimum number of input shares ) , it must be observed that such a responsibility should not only be that of the leader . Is there a plan to have aggregation size enforcement by the aggregators , and avoid aggregation of a small amount of ( even a single ) records ? 
 We did discuss that problem , but it 's good to have an open issue on it so we do n't forget to address it ; thank you for filing this ! One tricky dimension to this question is what the minimum threshold should be . I 'm not sure if a single threshold value is appropriate for all use cases , and it might be that it 's something the client should select while onboarding into the system . 
 Having that be a choice of the client is interesting , but such value would need to be visible to the leader ( since the leader needs to ask the aggregators to aggregate at least that number of shares together ) , but also need to be authenticated by the client for the aggregators ( so that the leader can not arbitrarily modify the value ) . This brings quite a few complications , especially with the optimization of using a KEM . Another option ( beyond enforcement by the aggregators , which I still find preferable ) could be for the aggregators to keep a public and transparent log of how many shares a specific leader asked to aggregate . Such a public log may act as a deterrent for leader to ask for small aggregations , and they would need a strong justification on why a small aggregation was performed . On the downside , this would reveal publicly how much data is flowing throughout the system . 
 My $ 0.02 : aggregators should enforce the number of input shares aggregated before releasing their share of the output . One way to do this is , as you suggested , might be to replace the KEM with IND - CCA - secure encryption --- say , full HPKE , which takes associated data --- and authenticate the threshold by passing it in as associated data . 
 I suggest we remove the client auth stuff atogether and punt to the PR we discussed today , then merge this bad boy .
Paragraph (version A):
In this section we discuss attacks that are not considered in the
above threat model, and suggest mitigations that could be
incorporated into implementations of this protocol or future
revisions of this specfication.
Paragraph (version A):
Attackers can impersonate Prio clients and submit large amounts of
false input in order to spoil aggregations.  Deployments could
require clients to authenticate before they may contribute inputs.
For example, by requiring submissions to be signed with a key trusted
by aggregators.  However some deployments may opt to accept the risk
of false inputs to avoid having to figure out how to distribute
trusted identities to clients.
Paragraph (version A):
In the current threat model, servers participating in the protocol
have no insight into the activities of clients except that they have
uploaded input into a Prio aggregation, meaning that clients could
covertly leak a user's data into some other channel which compromises
privacy.  If we introduce the notion of a trusted computing base
which can attest to the properties or activities of a client, then
users and aggregators can be assured that their private data only
goes into Prio.  For instance, clients could use the trusted
computing base to attest to software measurements over reproducible
builds, or a trusted operating system could attest to the client's
network activity, allowing external observers to be confident that no
data is being exfiltrated.
Paragraph (version A):
While the input shares transmitted by clients to aggregators reveal
nothing about the original input, the aggregator can still learn
auxiliary information received messages (for instance, source IP or
HTTP user agent), which can identify participating clients or permit
some attacks on robustness.  This is worse if client authentication
used, since incoming messages would be bound to a cryptographic
identity.  Deployments could include a trusted anonymizing proxy,
which would be responsible for receiving input shares from clients,
stripping any identifying information from them (including client
authentication) and forwarding them to aggregators.  There should
still be a confidential and authenticated channel from the client to
the aggregator to ensure that no actor besides the aggregator may
decrypt the input shares.
Paragraph (version B):
Client reports can contain auxiliary information such as source IP,
HTTP user agent or in deployments which use it, client authentication
information, which could be used by aggregators to identify
participating clients or permit some attacks on robustness.  This
auxiliary information could be removed by having clients submit
reports to an anonymizing proxy server which would then use Oblivous
HTTP I-D.thomson-http-oblivious to forward inputs to the PDA leader,
without requiring any server participating in PDA to be aware of
whatever client authentication or attestation scheme is in use.
Paragraph (version B):
An important parameter of a PDA deployment is the minimum batch size.
If an aggregation includes too few inputs, then the outputs can
reveal information about individual participants.  Aggregators use
the batch size field of the "PDAParams" structure to enforce minimum
batch size during the collect protocol, but server implementations
may also opt out of participating in a PDA task if the minimum batch
size is too small.  This document does not specify how to choose
minimum batch sizes.