Draft: draft-gpew-priv-ppm

Commentary: The spec vaguely refers to the " concrete PPM scheme " whenever we need to talk about protocol specific parameters . This change replaces each such reference with a reference to VDAF . It also adds the aggregation parameter to the aggregate request , which will be needed for hits . This is an alternative that aims to be less invasive . Partially addresses . 
 Squashed . 
 On the last design call ( 2021/08/04 ) we decided to split our work into two ( sets of ) documents : one for the " core " cryptographic protocols ( Prio , Hits , ... ) and another for the " wrapper " protocol ( basically the protocol bits we 've been working on so far ) . The next step is to specify the " interface " between these ( sets of ) documents . This is our goal for this issue . So far we 've been reasoning about this core - wrapper interface by analogy of HPKE and its applications ( ECH , OHTTP , etc . ) , which may indeed be an apt analogy , but it falls short of a precise definition . To that end , I 'd like to suggest that the interface needs to accomplish two things . ( 1 ) Specify the syntax of every PDA protocol . The syntax should cover : ( 1a ) generation of input shares from a measurement ; ( 1b ) the state machine of the leader and helper and how they respond to messages ( in the core protocol ) ; ( 1c ) accumulation of input shares into an output share ; and ( 1d ) combination of output shares into the output . ( 2 ) Specify the security requirements of every PDA protocol . This has three main components : ( 2a ) The expected communication model , which determines how much control over the network the adversary has . ( This may be different from the communication model of the wrapper protocol , as discussed below . ) ( 2b ) A baseline notion of privacy in the expected communication model that allows any number of clients and all but one aggregator to be corrupted . ( 2c ) A baseline notion of robustness in the expected communication that allows any number of corrupt clients to be corrupted , but requires all aggregators to be honest . Much of what we need is already worked out , but there are some gaps that require us to make some decisions . Two such gaps are discussed below . As observed in , we 've been considering attacks outside the formal model of either Prio or Hits ( specifically  and replay attacks ) . The communication model for the core protocol may therefore differ from ( i.e. , make stronger assumptions about the adversary than ) the communication model for the wrapper protocol . I would argue that this is perfectly reasonable . In fact , the main job of the wrapper protocol should be to " emulate " whatever communication model is expected by the core protocol . We are already well on our way here . The following mechanisms are used to provide properties that are implicit in the communication models of the papers : HPKE encryption creates a confidential channel between the client and each honest aggregator . The report 's timestamp and jitter fields define a total ordering on reports , which the aggregators can use to ensure each report is counted in at most one batch . Some bits are still missing , however : Who manages the report queue ? It seems simplest if the core protocol can assume in - order , non - repeated reports . The wrapper protocol can then do this enforcement . How are messages authenticated ? Currently , the adversary can impersonate the leader since leader - helper messages are not leader authenticated . This may lead to an attack on robustness . We should probably address this in the wrapper protocol such that the core protocol can assume these messages are authenticated . In Prio , the adversary learns nothing beyond the aggregate of the honest clients ' inputs . In contrast , in  , the adversary does n't just learn the heavy hitters ( HHs ) ; it may also learn the frequency of non - HH inputs that share a common prefix of a non - HH input with some HH . This leakage is inevitable because the aggregators learn each intermediate set of candidate prefixes at the start of each collect request . We 've observed that we can mitigate this leakage somewhat . Thus , one way to address this gap between Prio and Hits may be to require that each PDA protocol provide DP . This is probably too high a cost , however , given that not all PDA tasks need it . A simpler alternative might be to limit the syntax so that a single collect request is in scope . This seems natural , since a single round of  provides basically the same security properties as Prio . DP could still be , but this would merely augment whatever the baseline privacy goal aims to provide . 
 Much cleaner LGTM , modulo one typo
Paragraph (version A):
is to compute "y = F(x_1, ..., x_n)" for some aggregation function
"F" while revealing nothing else about the measurements.
Paragraph (version A):
Prio CGB17, which allows for aggregate statistics such as sum,
mean, histograms, etc. over a single value.
Paragraph (version A):
Heavy Hitters BBCGGI21, which allows for finding the most common
strings among a collection of clients (e.g., the URL of their home
page) as well as counting the number of clients that hold a given
string.
Paragraph (version B):
is to compute "y = F(p, x_1, ..., x_n)" for some aggregation function
"F" and aggregation parameter "p" while revealing nothing else about
the measurements.
Paragraph (version B):
The clients and servers need to agree on the aggregation function "F"
before running the protocol.  The aggregation parameter "p" is chosen
later by the servers, and the same set of measurements may be
aggregated multiple times with different aggregation parameters.
Paragraph (version B):
"prio3", which allows for aggregate statistics such as sum, mean,
histograms, etc.  This VDAF is based on Prio CGB17 and includes
improvements described in BBCGGI19.
Paragraph (version B):
"hits", which allows for finding the most common strings among a
collection of clients (e.g., the URL of their home page) as well
as counting the number of clients that hold a given string.  This
VDAF is the basis of the privacy preserving heavy hitters of
BBCGGI21.
Paragraph (version A):
The PPM scheme to use.  This is to some extent dictated by the
previous choices.
Paragraph (version B):
The type of each measurement.
Paragraph (version B):
The aggregation function to compute (e.g., sum, mean, etc.) and an
optional aggregation parameter.
Paragraph (version B):
The set of aggregators and necessary cryptographic keying material
to use.
Paragraph (version B):
The VDAF to execute, which to some extent is dictated by the
previous choices.
Paragraph (version A):
The leader distributes the shares to the helpers and orchestrates the
process of verifying them (see validating-inputs) and assembling them
into a final measurement for the collector.  Depending on the PPM
scheme, it may be possible to incrementally process each report as it
comes in, or may be necessary to wait until the entire batch of
reports is received.
Paragraph (version B):
The leader distributes the shares to the helpers and orchestrates the
process of verifying them (see validating-inputs) and assembling them
into a final measurement for the collector.  Depending on the VDAF,
it may be possible to incrementally process each report as it comes
in, or may be necessary to wait until the entire batch of reports is
received.
Paragraph (version A):
In order to address this problem, each PPM client generates a zero-
knowledge proof that its report is valid and attaches it to the
report.  The aggregators can then jointly verify this proof prior to
incorporating the report in the aggregation and reject the report if
it cannot be verified.  However, they do not learn anything about the
individual report other than that it is valid.
Paragraph (version B):
In order to address this problem, the aggregators engage in a secure,
multi-party computation, specified by the chosen VDAF, to ensure that
consuming the report will not corrupt the aggregate result.  The
input shares generated by the client include information used by the
aggregators during aggregation.  For example, "prio3" includes a
distributed zero-knowledge proof of the input's validity BBCGGI19
which the aggregators can jointly verify reject the report if it
cannot be verified.  However, they do not learn anything about the
individual report other than that it is valid.
Paragraph (version A):
"protocol": named parameter identifying the core PPM protocol,
e.g., Prio or Hits.
Paragraph (version B):
"protocol": named parameter identifying the VDAF scheme in use.
Paragraph (version A):
Some PPM schemes (e.g., Prio) allow the leader to start
aggregating reports proactively before all the reports in a batch
are received.  Others (e.g., Hits) require all the reports to be
present and must be initiated by the collector.
Paragraph (version A):
Processing the reports - especially verifying the proofs - may
require multiple round trips.
Paragraph (version A):
Note that it is possible to aggregate reports from one batch while
reports from the next batch are coming in.
Paragraph (version B):
Some VDAFs (e.g., "prio3") allow the leader to start aggregating
reports proactively before all the reports in a batch are
received.  Others (e.g., "hits") require all the reports to be
present and must be initiated by the collector.
Paragraph (version B):
Processing the reports - especially validating them - may require
multiple round trips.
Paragraph (version B):
Note that it is possible to aggregate reports from one batch while
reports from the next batch are coming in.  This is because each
report is validated independently.
Paragraph (version B):
The AggregateReq request is used by the leader to send a set of
reports to the helper.  These reports MUST all be associated with the
same PPM task and batch.
Paragraph (version A):
The "time", "nonce", and "extensions" fields have the same value as
those in the report uploaded by the client.  Similarly, the
"helper_share" field is the "EncryptedInputShare" from the "Report"
whose index in "Report.encrypted_input_shares" is equal to the index
of "[aggregator]" in the task's aggregator endpoints.  [OPEN ISSUE:
We usually only need to send this in the first aggregate request.
Shall we exclude it in subsequent requests somehow?]  The remainder
of the structure is dedicated to the protocol-specific request
parameters.
Paragraph (version B):
The "time", "nonce", and "extensions" fields have the same value as
those in the report uploaded by the client.  Similarly, the
"helper_share" field is the "EncryptedInputShare" from the "Report"
whose index in "Report.encrypted_input_shares" is equal to the index
of "[aggregator]" in the task's aggregator endpoints.  [OPEN ISSUE:
We usually only need to send this in the first aggregate request.
Shall we exclude it in subsequent requests somehow?]  The remainder
of the structure is dedicated to VDAF-specific request parameters.
Paragraph (version A):
The remainder of the message is dedicated to the protocol-specific
request parameters.
Paragraph (version A):
Depending on the PPM scheme and how the leader is configured, the
collect request may cause the leader to send a series of aggregate
requests to the helpers in order to compute their share of the
output.  Alternately, the leader may already have made these requests
and can respond immediately.  In either case it responds to the
collector's request as follows.
Paragraph (version B):
"agg_param", an aggregation parameter for the VDAF being executed.
Paragraph (version B):
Depending on the VDAF scheme and how the leader is configured, the
collect request may cause the leader to send a series of aggregate
requests to the helpers in order to compute their share of the
output.  Alternately, the leader may already have made these requests
and can respond immediately.  In either case it responds to the
collector's request as follows.