Draft: draft-pda-protocol

Commentary: Fixes a miscellany of typos , formatting errors and obsolete todos I encountered while reviewing the document . 
 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 .
Paragraph (version A):
Batch size: The minimum size of a batch.
Paragraph (version B):
Batch size: The minimum number of reports in a batch.
Paragraph (version A):
Collector: The endpoint that receives the output of the
aggreagtion function.  It also specifies the parameters of the
protocol.
Paragraph (version B):
Collector: The endpoint that receives the output of the
aggregation function.  It also specifies the parameters of the
protocol.
Paragraph (version A):
Proof: A value generated by the client used by the aggregators to
verify the client's input.
Paragraph (version B):
Proof: A value generated by the client and used by the aggregators
to verify the client's input.
Paragraph (version A):
The main cryptographic tool used for achieving this privacy goal is
_additive secret sharing_. Rather than send its input in the clear,
each client splits its measurements into a sequence of _shares_ and
sends a share to each of the aggregators.  Additive secret sharing
has two important properties: - It's impossible to deduce the
measurement without knowing _all_ of the shares.  - It allows the
aggregators to compute the final output by first adding up their
measurements shares locally, then combining the results to obtain the
final output.
Paragraph (version B):
It's impossible to deduce the measurement without knowing _all_ of
the shares.
Paragraph (version B):
It allows the aggregators to compute the final output by first
adding up their measurements shares locally, then combining the
results to obtain the final output.
Paragraph (version A):
section.)  It then uploads "X[1,1]" to one server "X[1,2]" to the
other.  The second client splits its measurement "x[2]" into "X[1,2]"
and "X[2,2]", uploads them to the servers, and so on.
Paragraph (version B):
section.)  It then uploads "X[1,1]" to one server and "X[1,2]" to the
other.  The second client splits its measurement "x[2]" into "X[1,2]"
and "X[2,2]", uploads them to the servers, and so on.
Paragraph (version B):
As noted above, each client has a collection of measurements that it
wants to send.  Each measurement is characterized by a set of
parameters that are centrally configured and provided to each client
(see pa-config).
Paragraph (version A):
"nonce": A unique sequence of bytes used to ensure that two
otherwise identical "PDAParam" instances will have distinct
"PDATaskID"s.  It is RECOMMENDED that this be set to a random
16-byte string derived from a cryptographically secure pseurandom
number generator.
Paragraph (version B):
"nonce": A unique sequence of bytes used to ensure that two
otherwise identical "PDAParam" instances will have distinct
"PDATaskID"s.  It is RECOMMENDED that this be set to a random
16-byte string derived from a cryptographically secure
pseudorandom number generator.
Paragraph (version A):
"batch_window": The batch window, i.e., the minimum time
difference between the oldest and newest report in a batch.
Paragraph (version B):
"batch_window": The window of time covered by a batch, i.e., the
maximum interval between the oldest and newest report in a batch.
Paragraph (version A):
We call this a _key configation_. The key configuration is used to
set up a base-mode HPKE context to use to derive symmetric keys for
protecting: (1) input shares sent from the client to an aggregator;
or (2) output shares sent from the helper to the collector.  The
_config id_, "HpkeConfig.id", is forwarded by the sender to the
receiver to help the receiver decide if it knows the decryption key.
Paragraph (version B):
We call this a _key configuration_. The key configuration is used to
set up a base-mode HPKE context to use to derive symmetric keys for
protecting: (1) input shares sent from the client to an aggregator;
or (2) output shares sent from the helper to the collector.  The
_config id_, "HpkeConfig.id", is forwarded by the sender to the
receiver to help the receiver decide if it knows the decryption key.
Paragraph (version A):
The aggregators agree on a set of PDA tasks, as well as the PDA
parameters associated to each task.
Paragraph (version B):
The clients, aggregators, and collector agree on a set of PDA
tasks, as well as the PDA parameters associated to each task.
Paragraph (version A):
"config_id" is equal to "HpkeConfig.id", where "HpkeConfig" is the
aggregator's key config.
Paragraph (version B):
"config_id" is equal to "HpkeConfig.id", where "HpkeConfig" is the
key config of the aggregator receiving the input share.
Paragraph (version A):
In order to provide replay protection, the leader is required to send
aggregate sub-requests in ascending order, where the ordering on sub-
requests is determined by the algorithm defined in anti-replay.
Specifically, the leader constructs its request such that: * each
sub-request follows the previous sub-request; and * the first sub-
request follows the last sub-request in the previous aggregate
request.
Paragraph (version B):
the first sub-request follows the last sub-request in the previous
aggregate request.
Paragraph (version A):
The helper state is an optional parameter of an aggregate request
that the can helper use to carry state across requests.  At least
part of the state will usually need to be encrypted in order to
protect user privacy.  However, the details of precisely how the
state is encrypted and the information that it carries is up to the
helper implementation.
Paragraph (version B):
The helper state is an optional parameter of an aggregate request
that the helper can use to carry state across requests.  At least
part of the state will usually need to be encrypted in order to
protect user privacy.  However, the details of precisely how the
state is encrypted and the information that it carries is up to the
helper implementation.
Paragraph (version A):
x := PRNG(k, n) denotes generation of a vector of n elements of K.
Paragraph (version A):
This can be instantiated using a standard stream cipher, e.g., AES-
CTR, as follows.  Interpret the seed k as the key and IV for
generating the AES-CTR key stream.  Proceed by rejection sampling, as
follows.  Let m be the number of bits needed to encode an element of
K.  Generate the next m bits of key stream and interpret the bytes as
an integer x, clearing the most significant m - l bits, where l is
the bit-length of the modulus p.  If x < p, then output x.
Otherwise, generate the next m bits of key stream and try again.
Repeat this process indefinitely until a suitable output is found.
Paragraph (version B):
"x := PRNG(k, n)" denotes generation of a vector of "n" elements
of "K".
Paragraph (version B):
This can be instantiated using a standard stream cipher, e.g., AES-
CTR, as follows.  Interpret the seed "k" as the key and IV for
generating the AES-CTR key stream.  Proceed by rejection sampling, as
follows.  Let "m" be the number of bits needed to encode an element
of "K".  Generate the next "m" bits of key stream and interpret the
bytes as an integer "x", clearing the most significant "m - l" bits,
where "l" is the bit-length of the modulus "p".  If "x < p", then
output "x".  Otherwise, generate the next "m" bits of key stream and
try again.  Repeat this process indefinitely until a suitable output
is found.