The definition of Time, Duration, Url, and QueryType follow those in
[DAP].¶
In addition, a new taskprov extension is offered in both Leader and Helper's
-report share:¶
-enum {
- task_prov(0xff00),
- (65535)
-} ExtensionType;
-¶
-The extension data in report share for task_prov is zero length, since its
-content is transported in "dap-taskprov" header.¶
When a Leader and Helper implement the task_prov extension in the context of a
+
When a Leader and Helper implement the taskprov extension in the context of a
particular DAP deployment, they SHOULD compute the shared VDAF verification key
[VDAF] as described in this section.¶
The Aggregators are presumed to have securely exchanged a pre-shared secret @@ -1471,7 +1459,7 @@
verify_key = HKDF-Expand(
HKDF-Extract(
- task_prov_salt, # salt
+ taskprov_salt, # salt
verify_key_init, # IKM
),
task_id, # info
@@ -1479,7 +1467,7 @@
)
¶
where task_prov_salt is defined to be the SHA-256 hash of the octet string
+
where taskprov_salt is defined to be the SHA-256 hash of the octet string
"dap-taskprov" and task_id is as defined in Section 3.1. Functions
HKDF-Extract() and HKDF-Expand() are as defined in [RFC5869]. Both functions
are instantiated with SHA-256.¶
Once the client opts in to a task, it MAY begin uploading reports for the task.
Each upload request for that task MUST advertise the task configuration. The
-extension codepoint task_prov MUST be offered in the extensions field of
+extension codepoint taskprov MUST be offered in the extensions field of
both leader and helper's PlaintextInputShare. In addition, each report's task
ID MUST be computed as described in Section 3.1.¶
The taskprov extension type is defined as follows:¶
+enum {
+ taskprov(0xff00),
+ (65535)
+} ExtensionType;
+¶
+The extension data in report share for taskprov is zero length, since its
+content is transported in "dap-taskprov" header.¶
Finally, once the Leader has opted in to the task, it completes the upload
-request as usual. During the process, if Leader's report share does not present
-a task_prov extension type, Leader SHOULD abort the upload request with
-"invalidMessage".¶
During the upload flow, if Leader's report share does not present a taskprov
+extension type, Leader MUST abort the upload request wit "invalidMessage".¶
The Collector might issue a collect request for a task provisioned by the Taskprov extension prior to opting in to the task. In this case, the Leader would need to abort the collect request with "unrecognizedTask". When it does -so, it SHOULD also include a "Retry-After" header in its HTTP response -indicating the time after which the Collector should retry its request.¶
+so, it is up to the Collector to retry its request.¶TODO: Find RFC reference for "Retry-After".¶
-OPEN ISSUE: This semantics is awkward, as there's no way for the Leader to -distinguish between Collectors who support the extension and those that don't.¶
+OPEN ISSUE: This semantics is awkward, as there's no way for the Leader to +distinguish between Collectors who support the extension and those that don't.¶
The Leader MUST advertise the task in every aggregate share request issued to -the Helper as described in Section 3.¶
+The Leader MUST advertise the task in every aggregate share request issued to +the Helper as described in Section 3.¶
Finally, the Helper completes the aggregate initialize request as usual,
deriving the VDAF verification key for the task as described in
-Section 3.2. During the process, if Helper's report share does not
-present a task_prov extension type, Helper SHOULD abort the aggregate request
-with "invalidMessage".¶
During Helper aggregate initialization, if Helper's report share does not
+present a taskprov extension type, Helper MUST abort the aggregate request
+with "invalidMessage".¶
If the Leader responds to a collect request with an "unrecognizedTask" error, -but the HTTP response includes a "Retry-After" header, the Collector SHOULD -retry its collect request after waiting for the duration indicated by the +the Collector MAY retry its collect request after waiting for a duration. header.¶
task_prov extension type in the report
+encryption. Furthermore, the presence of taskprov extension type in the report
share means Aggregators that do not recognize Taskprov extension must abort with
invalidMessage, as described in (Section 4.4.3 of [DAP]). This prevents a
-malicious Leader from provisioning a modified task in Helper with other means,
-which can lead to compromised privacy guarantee in aggregation results.¶
+malicious Author from provisioning a modified task to each party with other
+means, which can lead to compromised privacy guarantee in aggregate result.¶
OPEN ISSUE: What if the Collector and Aggregators don't agree on the task diff --git a/add-0len-ext-to-report/draft-wang-ppm-dap-taskprov.txt b/add-0len-ext-to-report/draft-wang-ppm-dap-taskprov.txt index 5b31ca7..83a02c9 100644 --- a/add-0len-ext-to-report/draft-wang-ppm-dap-taskprov.txt +++ b/add-0len-ext-to-report/draft-wang-ppm-dap-taskprov.txt @@ -5,8 +5,8 @@ Privacy Preserving Measurement S. Wang Internet-Draft Apple Inc. Intended status: Informational C. Patton -Expires: 15 April 2024 Cloudflare - 13 October 2023 +Expires: 16 April 2024 Cloudflare + 14 October 2023 In-band Task Provisioning for DAP @@ -51,7 +51,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 15 April 2024. + This Internet-Draft will expire on 16 April 2024. Copyright Notice @@ -297,17 +297,6 @@ Table of Contents The definition of Time, Duration, Url, and QueryType follow those in [DAP]. - In addition, a new taskprov extension is offered in both Leader and - Helper's report share: - - enum { - task_prov(0xff00), - (65535) - } ExtensionType; - - The extension data in report share for task_prov is zero length, - since its content is transported in "dap-taskprov" header. - 3.1. Deriving the Task ID When using the Taskprov extension, the task ID is computed as @@ -320,7 +309,7 @@ Table of Contents 3.2. Deriving the VDAF Verification Key - When a Leader and Helper implement the task_prov extension in the + When a Leader and Helper implement the taskprov extension in the context of a particular DAP deployment, they SHOULD compute the shared VDAF verification key [VDAF] as described in this section. @@ -335,14 +324,14 @@ Table of Contents verify_key = HKDF-Expand( HKDF-Extract( - task_prov_salt, # salt + taskprov_salt, # salt verify_key_init, # IKM ), task_id, # info VERIFY_KEY_SIZE, # L ) - where task_prov_salt is defined to be the SHA-256 hash of the octet + where taskprov_salt is defined to be the SHA-256 hash of the octet string "dap-taskprov" and task_id is as defined in Section 3.1. Functions HKDF-Extract() and HKDF-Expand() are as defined in [RFC5869]. Both functions are instantiated with SHA-256. @@ -406,11 +395,21 @@ Table of Contents Once the client opts in to a task, it MAY begin uploading reports for the task. Each upload request for that task MUST advertise the task - configuration. The extension codepoint task_prov MUST be offered in + configuration. The extension codepoint taskprov MUST be offered in the extensions field of both leader and helper's PlaintextInputShare. In addition, each report's task ID MUST be computed as described in Section 3.1. + The taskprov extension type is defined as follows: + + enum { + taskprov(0xff00), + (65535) + } ExtensionType; + + The extension data in report share for taskprov is zero length, since + its content is transported in "dap-taskprov" header. + 5. Leader Behavior 5.1. Upload Protocol @@ -437,9 +436,11 @@ Table of Contents to report this to the Author? Finally, once the Leader has opted in to the task, it completes the - upload request as usual. During the process, if Leader's report - share does not present a task_prov extension type, Leader SHOULD - abort the upload request with "invalidMessage". + upload request as usual. + + During the upload flow, if Leader's report share does not present a + taskprov extension type, Leader MUST abort the upload request wit + "invalidMessage". 5.2. Aggregate Protocol @@ -453,11 +454,8 @@ Table of Contents The Collector might issue a collect request for a task provisioned by the Taskprov extension prior to opting in to the task. In this case, the Leader would need to abort the collect request with - "unrecognizedTask". When it does so, it SHOULD also include a - "Retry-After" header in its HTTP response indicating the time after - which the Collector should retry its request. - - TODO: Find RFC reference for "Retry-After". + "unrecognizedTask". When it does so, it is up to the Collector to + retry its request. OPEN ISSUE: This semantics is awkward, as there's no way for the Leader to distinguish between Collectors who support the extension @@ -493,8 +491,10 @@ Table of Contents Finally, the Helper completes the aggregate initialize request as usual, deriving the VDAF verification key for the task as described - in Section 3.2. During the process, if Helper's report share does - not present a task_prov extension type, Helper SHOULD abort the + in Section 3.2. + + During Helper aggregate initialization, if Helper's report share does + not present a taskprov extension type, Helper MUST abort the aggregate request with "invalidMessage". 7. Collector Behavior @@ -510,9 +510,8 @@ Table of Contents advertise the task as described in Section 3. If the Leader responds to a collect request with an - "unrecognizedTask" error, but the HTTP response includes a "Retry- - After" header, the Collector SHOULD retry its collect request after - waiting for the duration indicated by the header. + "unrecognizedTask" error, the Collector MAY retry its collect request + after waiting for a duration. header. 8. Security Considerations @@ -528,12 +527,12 @@ Table of Contents 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. Furthermore, the presence of task_prov extension + HPKE encryption. Furthermore, the presence of taskprov extension type in the report share means Aggregators that do not recognize Taskprov extension must abort with invalidMessage, as described in - (Section 4.4.3 of [DAP]). This prevents a malicious Leader from - provisioning a modified task in Helper with other means, which can - lead to compromised privacy guarantee in aggregation results. + (Section 4.4.3 of [DAP]). This prevents a malicious Author from + provisioning a modified task to each party with other means, which + can lead to compromised privacy guarantee in aggregate result. OPEN ISSUE: What if the Collector and Aggregators don't agree on the task configuration? Decryption should fail.