Change:
4.4.1.3. Each report share has a corresponding task ID, report metadata <del> (report ID, timestamp, and extensions), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </del> <ins> (report ID and, timestamp), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </ins> "encrypted_input_share.config_id".  If not found, then it marks the report share as invalid with the error "hpke_unknown_config_id". Otherwise, it constructs an "InputShareAad" message from "task_id",

Discussion:
Rebased and squashed.
Rebased and squashed.
NAME I've removed the shared extensions as discussed. Can you take another look and re-approve?
As noted by NAME in URL, we need to decide how to handle duplicate extensions. One simple idea is to treat duplicate extensions as decoding failures, i.e., abort with "unrecognizedMessage".
Are unknown/unsupported extensions ignored?
First off, just for clarity's sake, I'm assuming Martin is talking about . I think there are three ways to solve this problem. First, unknown extensions could be ignored by the aggregators. I believe this is the intent of the existing text (though I acknowledge that the protocol text would need to be updated to make that clear). I think this would work for the two report extension use cases I'm aware of at the moment, which are client authentication to the helper and . In either case, the aggregator can ignore the extension, proceed with the protocol and I don't think anything disastrous happens. If the aggregator doesn't support client auth extensions, it simply proceeds with processing the report upload after applying whatever other security policy it wants to the report. If the aggregator doesn't support the taskprov extension, then the upload will fail gracefully and reliably because the aggregator doesn't recognize the task ID referenced by the report. This is simple and flexible, but it does mean that all extensions ever deployed in DAP need to be designed such that they can be gracefully ignored by aggregators. The second way to handle this would be to use something like (ugh) X.509's extension criticality bit, which would appear alongside an extension and if set to true, would indicate to servers that they should abort processing of an upload with some error like , the idea being that further handling of the report without handling the extension is too dangerous. However, anytime I'm reaching out to (ugh) X.509 for ideas, I take that as a sign that maybe we're solving the wrong problem or doing something too complicated. But I think the reason X.509 ends up needing a criticality bit is because at the time of issuance of a certificate, it's not known (and not knowable) what is the set of implementations of relying parties, servers, CT logs, audit tools, etc. that might ever see the cert, and so special care must be taken to account for the diversity of implementations.

But in DAP, when a client is putting extensions into its reports, it's doing so with knowledge of the specific pair of aggregators to which it is uploading the report, so I think it's more reasonable to expect the client to know precisely what extensions the aggregators support. We have discussed having servers advertise what HPKE algorithms they support in , so advertising supported extensions is a minor step beyond that. So the third option is to treat all extensions as critical, and require servers to abort if they don't recognize them. This is the least flexible, but I also think it's the easiest one to reason about, both for the DAP protocol and eventual extension authors. All that said, I think I'll tentatively vote for all extensions implicitly being critical, but I'm open to having my mind changed.
I would prefer to make extensions ignored by default, as they are in TLS. That puts it to extension designers to make sure their extensions can be safely ignored. If an extension can't be safely ignored, we should consider merging it into the core protocol. See URL for additional discussion.
To be clear NAME the spec is not clear here yet, hence :)
I apologize for splitting the discussion. I tend to side with NAME conclusions. If nothing else, the aggregators can publish what they accept ahead of time, along with keys.
I think my only concern with the third option is this: Suppose that, in some DAP deployment, the Client and Leader used some extension that is irrelevant to the Helper. For instance, imagine the Client produces some attestation () that the report was generated on a Leader-trusted device. The Helper may not be able to do this check. I guess you could argue that both Aggregators should be doing this check, in which case option 3 is actually what we want? This would probably depend on the threat model for the extension.
So are these extensions universal in the sense that the same extension applies to the data that is sent to all helpers (including the leader) or, as I believe is the case, the extensions are targeted and they are sent separately to each of the helpers? In the latter case, the client can condition what it sends on what it knows about the specific helper that it is sending to. Yes, that makes it more complicated for a client, but that is the nature of the trade-off.

The latter is what I'm imagining, yes. Hmm that's a pretty good idea, though (1) it would require some protocol changes (currently the Leader "re-transmits" all of the extensions to each Helper) and (2) we would have to unbind the extensions from the HPKE ciphertext (currently the extensions are included in the AAD for encryption). (1) seems workable to me; (2) doesn't seem desirable from a security perspective. (Fiddling with extensions should result in the report being excluded, hence the current binding.)
Thinking about it more, we don't have to do (2). Perhaps all we have to do is mark each extension with the identity of the intended consumer? Some extensions might be intended for the Leader, others for the Helper, others for both.
Why not move the extensions to the encrypted payload? Sure, the client replicates extensions toward each helper, but you avoid a lot of this complexity.
That could work, but I think we should avoid copying extensions. (People are worried about communication cost of DAP.)
I'd be down for something like this: Treat Report.extensions as "critical", in the sense that any unrecognized extension triggers an abort. Add an extensions field to the plaintext for each Report.encryptedinputshare.payload (HPKE ciphertext). Alternatively, we could add a new field to Report.encryptedinputshare. Either way, the consumer treats these as critical. NAME WDYT?
The idea being to (1) enable a client to send different extensions to either aggregator and (2) keep the extensions intended for the helper private from the leader? Yeah, seems like a good idea!
It would be great to work this out in DAP-03. I'll try to put together a PR for NAME suggestion next week, if no one else gets there first.
PR is up, please have a look!
Noticed a typo, otherwise LGTM.