search

ietf-wg-ppm / draft-ietf-ppm-dap-taskprov

Define DAP extension for in-band task provisioning.
Other
2 stars 3 forks source link

Non-Taskprov Aggregators may have an inconsistent view of task parameters #39

Closed divergentdave closed 1 year ago

divergentdave commented 1 year ago

The Security Considerations section currently says:

In particular, if the Clients and Aggregators have an inconsistent view of the the task configuration, then aggregation of reports will fail. This is guaranteed by the binding of the task ID (derived from the task configuration) to report shares provided by HPKE encryption.

This is not the case if one of the Aggregators doesn't use Taskprov, but instead accepts task parameters (including task ID and VDAF verify key) via some other means. A dishonest Aggregator could read the DAP-Taskprov header, rewrite parts of it, provision the rewritten task in the honest Aggregator using some other means, and then proceed to successfully aggregate reports. This could be addressed by adding a zero-length extension to report shares, as honest Aggregators that don't support Taskprov will reject reports with unknown extensions.

This attack scenario may be a little far-fetched, as in practice I think aggregators will advertise if they support Taskprov. Furthermore, I think it will be common for other kinds of DAP deployments to define their own incompatible derivation relationships between the task_id and vdaf_verify_key. This came up while writing up ietf-wg-ppm/draft-ietf-ppm-dap#500.

wangshan commented 1 year ago

A dishonest Aggregator could read the DAP-Taskprov header, rewrite parts of it, provision the rewritten task in the honest Aggregator using some other means, and then proceed to successfully aggregate reports.

You are right the attack does exist, we should consider adding extension codepoint to report shares, it's a small cost to pay to resolve this issue (similar to what taskprov-02 did when dap-02 has extension on report level, but with zero length extension data).

what do you think @cjpatton? Can we propose that and make taskprov a proper extension of DAP?

cjpatton commented 1 year ago

(sorry for the late reply, I was busy at a conference last week) I agree this is a valid cross-protocol attack. Let's add a defense for it. Good catch @divergentdave as always.