Collector configuration endpoint

[tgeoghegan]

PPM uses HPKE to achieve confidentiality and authenticity independently of the underlying transport. To that end, any server that receives messages in the protocol must provide an HPKE configuration to other entities so that messages can be encrypted.

For the leader and helper servers, this is achieved by the leader_url and helper_url fields (respectively) in struct PPMParam. Those servers' current HPKE configs can then be obtained from a well-defined HTTP endpoint relative to those URLs.

For the collector, we instead have HpkeConfig collector_config in struct PPMParam. The advantage of this approach is that it absolves the collector of needing to act as an HTTP server, since the collector otherwise is merely a client of the leader's collect endpoint. The downsides are that it's different from the other servers, which is a bit surprising and unappealing, and that it makes it impossible to rotate a collector's HPKE key without constructing and distributing a new struct PPMParam to all the participants, which includes the potentially numerous clients, in spite of the fact that none of them will ever need to encrypt messages to the collector.

This issue tracks improvements to collector configuration discovery. We should consider making collector HPKE configs discoverable the same way that leader and helper ones are, weighing that against the extra operational burden placed on collectors.

[tgeoghegan]

Per today's design meeting, putting in the parking lot for now, as this doesn't need to block prototyping or other forward progress on the protocol.

[cjpatton]

Hey @tgeoghegan, this issue make some pretty crusty references, including to PPMParam!!! It would be useful to get an update on this issue. How are you thinking about it now?

My take is that this is something we still want to be deployment specific. I would suggest we close it.

[tgeoghegan]

Yeah, PPMParam is a non-sequitur now, a year later, but I think the core issue still exists, which is that we can't rotate collector HPKE configs without defining new tasks. I still think that's a problem we should consider.

[cjpatton]

As of #411, the VDAF verification key is immutable over the lifetime of a task. It seems like we could get away with pegging the HPKE collector config to the task as well.

In either case, do you think we can close this issue in favor of a solution to #237? We would need to update a reference to this issue in the text.

[cjpatton]

@tgeoghegan: We need to make sure that the spec doesn't forbid rotating the collector HPKE config over a task's lifetime.

[tgeoghegan]

Apparently we reached the exact opposite conclusion back in #237, and at that time decided to add language that explicitly forbids rotating collector HPKE configurations (ref).

A task's parameters are immutable for the lifetime of that task. The only way to change parameters or to rotate secret values like collector HPKE configuration and the VDAF verification key is to define a new task.

I'm inclined to stick with the decision made in #237 and not do anything here. I'll close this issue in another 24 hours unless someone objects.

[cjpatton]

Ah! good catch. I'd say this is up to you guys: if the restriction is workable for Divvi Up, then let's close.

[tgeoghegan]

Closing, on the premise that in DAP, key rotation means task rotation.