Re: [Ppm] Seeking input on DAP PR #297

[Christopher Patton <[e-mail]>]

> First, the statement "the Client knows exactly which batch its report is
> included" is dubious. While the client technically knows that its report
> is in a batch that covers its timestamp, this does not constrain when
> that batch starts or ends, how many other reports there are in it, which
> reports from the same time window have been dropped, etc. So what kind
> of useful assurances can the client derive from this?
>

That's the question here :)

Only one thing comes to mind for me. Without (3.), it seems easy for a
malicious Leader to do a Sybil attack "on the side". In DAP-01, the Leader
can aggregate a batch of one honest report with min_batch_size -1 bogus
reports and, colluding with the Collector, learn the aggregate result.
However this attack has a cost: because the batch corresponds to an
interval of time which MUST NOT overlap with any previous or future batch
interval, the Leader has to throw away all other honestly generated reports
in the target interval. Without (3.) -- suppose we decide in DAP-02 not to
send the batch interval in the AggregateShareReq -- the Leader can run this
bogus aggregation on the side, without impacting throughput of real reports.

Now, the fact that (3.) imposes this cost does not immediately benefit the
Client, but perhaps there is a way to audit the Leader to make sure it's
ingesting reports properly. (This is a bit contrived, but follow along with
me for a second.) In particular, after the batch interval elapses in which
its report would have been included, the Client could ask the Leader and
Helper to see if its report was ingested.

Of course, this attack falls into a bucket of other Sybil attacks that we
currently don't have defenses for. We're not likely to find a
one-size-fits-all solution for this problem, but it seems like there is a
lot we can do to at least mitigate Sybil attacks or make them harder.
Property (3.) seems to me like it would help.

That said, I view this as a "nice to have", but not a requirement for all
query types. I would like to spell the protocol in a way that enables it.



> Second, there are technical issues. It is not clear that property (1.)
> holds because it clashes with
> https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/183. We just
> have it because we haven't sorted out
> https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/195 yet.
>

We have (1.) because we prevent batches from overlapping, i.e., we have
(2.). You're right that, if/when we relax (2.), we'll definitely have to do
something else.

Chris P.