Draft: draft-ietf-ppm-dap

Commentary: Rebased and squashed . 
 Rebased and squashed . 
 I 've removed the shared extensions as discussed . Can you take another look and re - approve ? 
 As noted by in , 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  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 do n't think anything disastrous happens . If the aggregator does n'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 does n't support the taskprov extension , then the upload will fail gracefully and reliably because the aggregator does n'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 do n'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 ca n't be safely ignored , we should consider merging it into the core protocol . See for additional discussion . 
 To be clear the spec is not clear here yet , hence :) 
 I apologize for splitting the discussion . I tend to side with 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  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 ) does n'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 do n'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 : Report.extensions as " critical " , in the sense that any unrecognized extension triggers an abort . 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 .  ? 
 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 suggestion next week , if no one else gets there first . 
 PR is up , please have a look ! 
 Noticed a typo , otherwise LGTM .
Paragraph (version A):
where "pk" is the aggregator's public key; "server_role" is the Role
of the intended recipient ("0x02" for the leader and "0x03" for the
helper), "input_share" is the Aggregator's input share, and
"input_share_aad" is an encoded message of type "InputShareAad",
constructed from the same values as the corresponding fields in the
report.  The "SealBase()" function is as specified in HPKE for the
ciphersuite indicated by the HPKE configuration.
Paragraph (version B):
Field "extensions" is set to the list of extensions intended to be
consumed by the given Aggregator.  (See upload-extensions.)  Field
"payload" is set to the Aggregator's input share output by the VDAF
sharding algorithm.
Paragraph (version B):
where "pk" is the aggregator's public key; "server_role" is the Role
of the intended recipient ("0x02" for the leader and "0x03" for the
helper), "plaintext_input_share" is the Aggregator's
PlaintextInputShare, and "input_share_aad" is an encoded message of
type "InputShareAad", constructed from the same values as the
corresponding fields in the report.  The "SealBase()" function is as
specified in HPKE for the ciphersuite indicated by the HPKE
configuration.
Paragraph (version A):
"extension_type" indicates the type of extension, and
"extension_data" contains information specific to the extension.
Paragraph (version B):
If the Report contains an unrecognized extension, then the Leader MAY
abort the upload request with error "unrecognizedMessage".  Note that
this behavior is not mandatory because it requires the Leader to
decrypt its input share.
Paragraph (version B):
Field "extension_type" indicates the type of extension, and
"extension_data" contains information specific to the extension.
Paragraph (version A):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).  If
decryption fails, the aggregator marks the report share as invalid
with the error "hpke_decrypt_error".  Otherwise, it outputs the
resulting "input_share".  The "OpenBase()" function is as specified
in HPKE for the ciphersuite indicated by the HPKE configuration.
Paragraph (version B):
Check if the PlaintextInputShare contains unrecognized extensions.
If so, then the Aggregator MUST mark the input share as invalid
with error "unrecognized_message".
Paragraph (version A):
"vdaf_verify_key" is the VDAF verification key shared by the
aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and
"0x01" for the helper); "agg_param" is the opaque aggregation
parameter distributed to the aggregators by the collector;
"public_share" is the public share generated by the client and
distributed to each aggregator; and "input_share" is the aggregator's
input share.
Paragraph (version B):
"vdaf_verify_key" is the VDAF verification key shared by the
aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and
"0x01" for the helper); "agg_param" is the opaque aggregation
parameter distributed to the aggregators by the collector;
"public_share" is the public share generated by the client and
distributed to each aggregator; and "plaintext_input_share" is the
aggregator's PlaintextInputShare.