Security considerations: privacy impact of per-task HpkeConfigs

[divergentdave]

We may want to make note of the fact that the helper sees IP addresses of clients only during /hpke_config requests. Therefore the helper will see the combination of IP addresses and task IDs if using per-task HpkeConfigs, or IP addresses alone if not. This is a smaller difference (note that the leader sees them together either way) but we may want to note it as a consideration for choosing whether to use per-task HpkeConfigs. Note that OHTTP proxies would mitigate this.

h/t @tgeoghegan

[cjpatton]

Relatedly: one benefit of 1-byte IDs for HpkeConfigs is that it reduces the "fingerprinting" surface by restricting the number of possible distinct IDs.

I don't recall if we did this mindfully; as I recall we just copy-pasted this from ECH. @chris-wood do you remember how we eneded up shortening the HpkeConfig ID in ECH to one byte? Was this about fingerprinting or something else?

[chris-wood]

That was precisely the reason.

[tgeoghegan]

This issue initially was about adding a security consideration, but I think we should do a couple other things in these paragraphs that seem related. There's a TODO lurking in this text:

[TODO: Allow Aggregators to return HTTP status code 403 Forbidden in deployments that use authentication to avoid leaking information about which tasks exist.]

Additionally, I don't know if this prescription is necessary:

Clients retrieve the HPKE configuration from each Aggregator by sending an HTTP GET request to {aggregator}/hpke_config. Clients MAY specify a query parameter task_id whose value is the task ID whose HPKE configuration they want. If the Aggregator does not recognize the task ID, then it MUST abort with error unrecognizedTask.

We don't need a DAP-layer error. An HTTP client error should suffice (as usual, implementations can put a problem document in the body of the HTTP 4XX if they want). Note that I still think we need the missingTaskID langauge that instructs clients to "upgrade" their HPKE config request if the aggregator doesn't use global HPKE configs.

[tgeoghegan]

I and others have come around to a new proposal here: we should do away with per-task HPKE keys altogether. The primary motivation for this is to reduce the complexity of the protocol: if only global HPKE keys are supported, then we can remove the task ID query parameter from the /hpke_config route and remove the description of the fallback logic.

I have two more arguments in favour of doing this.

Oblivious HTTP

Recently, we've been experimenting with composing DAP with Oblivious HTTP. The intent is to prevent the aggregators from learning which clients are participating in which tasks. If DAP uploads go over OHTTP, then the leader gets to see client-identifying metadata and in some settings, participating in some task can leak information (i.e., the user has opted into some data collection or has been assigned to some cohort).

But just doing uploads over OHTTP is insufficient: the helper and leader both get to see the clients and which task they are participating in when they fetch per-task HPKE configs. We could also serve HPKE configs over OHTTP, but this is kind of unsatisfactory: HPKE configs are static content that changes rarely, making it natural to delegate serving them to a content delivery network. Serving them over OHTTP is more expensive and a burden for aggregators. However, if you serve global HPKE keys, then aggregators no longer get to learn which clients are participating in which tasks.

This still lets the aggregators learn that some client may participate in DAP tasks at all in the future (it's also possible that clients will fetch HPKE keys but never upload). It'd be better to avoid this, but let's think about OHTTP again. That protocol also uses HPKE to protect messages as they transit through a third party, the OHTTP relay. In order to make sure you're delivering messages to the intended gateway, OHTTP suggests a mechanism for fetching OHTTP HPKE keys from the gateway. So that means that no matter what you do about serving DAP HPKE configs over OHTTP, the OHTTP HPKE key fetches will reveal the same information anyway. The conclusion we at Divvi Up reached is that you might as well serve global DAP HPKE keys without OHTTP, because you don't learn anything additional past what you learned from the OHTTP key fetches.

We think that composing DAP with OHTTP is going to be a very common deployment pattern, and so deployments may wind up using exclusively global HPKE keys anyway. Additionally, taskprov mandates global HPKE keys.

TLS equivalency

Recall that the reason we use HPKE at all is to build an authenticated, encrypted channel from the client to the helper. The helper receives the client's report shares from the leader in aggregation job initialization messages. But let's suppose DAP had shaken out differently and we did have clients upload report shares directly to the helper. Then we would simply rely on TLS to provide the authenticated, encrypted channel, and we wouldn't think twice about a single certificate and hence key being used for all tasks. So going from per-task HPKE keys to global ones should equivalently be acceptable.

Next steps

The DAP editors and several implementers agree that this change is a good idea. If we don't hear any objections, we'll be making that change on Friday, July 5.

[cjpatton]

Just to nit-pick one thing:

@tgeoghegan: Recall that the reason we use HPKE at all is to build an authenticated, encrypted channel from the client to the helper.

This "channel" is not client-authenticated. To more a bit more precise, we need non-malleability, not authenticity.

[tgeoghegan]

Just to nit-pick one thing:

@tgeoghegan: Recall that the reason we use HPKE at all is to build an authenticated, encrypted channel from the client to the helper.

This "channel" is not client-authenticated. To more a bit more precise, we need non-malleability, not authenticity.

I agree about non-malleability, but I think it is important that the server authenticate to the client, in the sense that the client wants to be sure that only the helper it fetched an HPKE configuration from could decrypt the report share. Perhaps that's already captured by the non-malleability property?

[cjpatton]

Just to nit-pick one thing:

@tgeoghegan: Recall that the reason we use HPKE at all is to build an authenticated, encrypted channel from the client to the helper.

This "channel" is not client-authenticated. To more a bit more precise, we need non-malleability, not authenticity.

I agree about non-malleability, but I think it is important that the server authenticate to the client, in the sense that the client wants to be sure that only the helper it fetched an HPKE configuration from could decrypt the report share. Perhaps that's already captured by the non-malleability property?

Yes it's important that the client has the correct public key, but this isn't provided by HPKE on its own.

[cjpatton]

Decision at IETF 120 was to merge @tgeoghegan's PR.