Draft: draft-ietf-ppm-dap

Commentary: This change is primarily editorial and includes the following changes : Replace references to " Prio " with references to a generic VDAF . ( This section was written long ago when we had Prio in mind . ) Elaborate on known issues for collect requests .   attacks , including enumerating the different types ( ) . 
 From dkg in Vienna : 
 It seems like there are a bunch of assumptions about Sybil attacks generally that are not well articulated yet . This would certainly help . 
 The list of attacks is really a list of things we ought to fix in the protocol , so I would not even bother including them in the security considerations . If we want to use this as an opportunity to identify open issues that need to be addressed before we consider the protocol secure , I would simply list the open issues and keep discussion in GitHub . ( That is , the text here seems redundant with the issue )
Paragraph (version A):
Prio assumes a powerful adversary with the ability to compromise an
unbounded number of clients.  In doing so, the adversary can provide
malicious (yet truthful) inputs to the aggregation function.  Prio
also assumes that all but one server operates honestly, where a
dishonest server does not execute the protocol faithfully as
specified.  The system also assumes that servers communicate over
secure and mutually authenticated channels.  In practice, this can be
done by TLS or some other form of application-layer authentication.
Paragraph (version A):
Privacy.  The aggregators and collector learn only the output of F
computed over all client inputs, and nothing else.
Paragraph (version A):
Robustness.  As long as the aggregators execute the input-
validation protocol correctly, a malicious client can skew the
output of F only by reporting false (untruthful) input.  The
output cannot be influenced in any other way.
Paragraph (version A):
Aggregation function choice.  Some aggregation functions leak
slightly more than the function output itself.
Paragraph (version B):
PPM assumes an active attacker that controls the network and has the
ability to statically corrupt any number of clients, aggregators, and
collectors.  That is, the attacker can learn the secret state of any
party prior to the start of its attack.  For example, it may coerce a
client into providing malicious input shares for aggregation or
coerce an aggregator into diverting from the protocol specified
(e.g., by divulging its input shares to the attacker).
Paragraph (version B):
Privacy.  Clients trust that some aggregator is honest.  That is,
as long as at least one aggregator executes the protocol
faithfully, the parties learn nothing beyond the aggregate result
(i.e., the output of the aggregation function computed over the
honest measurements).
Paragraph (version B):
Correctness.  The collector trusts that the aggregators execute
the protocol correctly.  That is, as long as the aggregators
execute the protocol faithfully, a malicious client can skew the
aggregate result only by reporting a false (untruthful)
measurement.  The result cannot be influenced in any other way.
Paragraph (version B):
Currently, the specification does not achieve these goals.  In
particular, there are several open issues that need to be addressed
before these goals are met.  Details for each issue are below.