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

[Simon Friedberger <[e-mail]>]

The leader can select the batches which will get aggregated which allows a
powerful Sybil attack.
I think there was an implicit assumption that the leader is somewhat
restricted here due to `min_batch_duration` and the requirement for batches
not to overlap.

Now, with fixed size tasks we lose the restriction on `min_batch_duration`
and with something like location-based batches as described in #183 we lose
the non-overlapping property.

Ideas for fixes:
1. We could have the collector sign the request and the helper authenticate
it. However, that would require non-collusion between leader and collector
to be useful. And then the collector might still be able to inject fake
reports fairly easily and do a similar attack.
2. A non-colluding OHTTP proxy might help because it can prevent the leader
from identifying individual reports.

On Mon, Aug 15, 2022 at 5:17 PM Christopher Patton <[e-mail]>
wrote:

>
>
>
>> 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.
>
>