Skip to content

Commit

Permalink
Script updating gh-pages from 4eb32f1. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Oct 14, 2023
1 parent b4796e6 commit 8cc4f80
Show file tree
Hide file tree
Showing 2 changed files with 69 additions and 77 deletions.
77 changes: 35 additions & 42 deletions add-0len-ext-to-report/draft-wang-ppm-dap-taskprov.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1033,7 +1033,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Wang &amp; Patton</td>
<td class="center">Expires 15 April 2024</td>
<td class="center">Expires 16 April 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1046,12 +1046,12 @@
<dd class="internet-draft">draft-wang-ppm-dap-taskprov-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-10-13" class="published">13 October 2023</time>
<time datetime="2023-10-14" class="published">14 October 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-04-15">15 April 2024</time></dd>
<dd class="expires"><time datetime="2024-04-16">16 April 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1106,7 +1106,7 @@ <h2 id="name-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."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 15 April 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 16 April 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1426,18 +1426,6 @@ <h2 id="name-the-taskprov-extension">
</ul>
<p id="section-3-13">The definition of <code>Time</code>, <code>Duration</code>, <code>Url</code>, and <code>QueryType</code> follow those in
<span>[<a href="#DAP" class="cite xref">DAP</a>]</span>.<a href="#section-3-13" class="pilcrow"></a></p>
<p id="section-3-14">In addition, a new <code>taskprov</code> extension is offered in both Leader and Helper's
report share:<a href="#section-3-14" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-3-15">
<pre>
enum {
task_prov(0xff00),
(65535)
} ExtensionType;
</pre><a href="#section-3-15" class="pilcrow"></a>
</div>
<p id="section-3-16">The extension data in report share for <code>task_prov</code> is zero length, since its
content is transported in "dap-taskprov" header.<a href="#section-3-16" class="pilcrow"></a></p>
<div id="construct-task-id">
<section id="section-3.1">
<h3 id="name-deriving-the-task-id">
Expand All @@ -1458,7 +1446,7 @@ <h3 id="name-deriving-the-task-id">
<h3 id="name-deriving-the-vdaf-verificat">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-deriving-the-vdaf-verificat" class="section-name selfRef">Deriving the VDAF Verification Key</a>
</h3>
<p id="section-3.2-1">When a Leader and Helper implement the <code>task_prov</code> extension in the context of a
<p id="section-3.2-1">When a Leader and Helper implement the <code>taskprov</code> extension in the context of a
particular DAP deployment, they <span class="bcp14">SHOULD</span> compute the shared VDAF verification key
<span>[<a href="#VDAF" class="cite xref">VDAF</a>]</span> as described in this section.<a href="#section-3.2-1" class="pilcrow"></a></p>
<p id="section-3.2-2">The Aggregators are presumed to have securely exchanged a pre-shared secret
Expand All @@ -1471,15 +1459,15 @@ <h3 id="name-deriving-the-vdaf-verificat">
<pre>
verify_key = HKDF-Expand(
HKDF-Extract(
task_prov_salt, # salt
taskprov_salt, # salt
verify_key_init, # IKM
),
task_id, # info
VERIFY_KEY_SIZE, # L
)
</pre><a href="#section-3.2-5" class="pilcrow"></a>
</div>
<p id="section-3.2-6">where <code>task_prov_salt</code> is defined to be the SHA-256 hash of the octet string
<p id="section-3.2-6">where <code>taskprov_salt</code> is defined to be the SHA-256 hash of the octet string
"dap-taskprov" and <code>task_id</code> is as defined in <a href="#construct-task-id" class="auto internal xref">Section 3.1</a>. Functions
HKDF-Extract() and HKDF-Expand() are as defined in <span>[<a href="#RFC5869" class="cite xref">RFC5869</a>]</span>. Both functions
are instantiated with SHA-256.<a href="#section-3.2-6" class="pilcrow"></a></p>
Expand Down Expand Up @@ -1557,9 +1545,20 @@ <h2 id="name-client-behavior">
</ul>
<p id="section-4-3">Once the client opts in to a task, it <span class="bcp14">MAY</span> begin uploading reports for the task.
Each upload request for that task <span class="bcp14">MUST</span> advertise the task configuration. The
extension codepoint <code>task_prov</code> <span class="bcp14">MUST</span> be offered in the <code>extensions</code> field of
extension codepoint <code>taskprov</code> <span class="bcp14">MUST</span> be offered in the <code>extensions</code> field of
both leader and helper's <code>PlaintextInputShare</code>. In addition, each report's task
ID <span class="bcp14">MUST</span> be computed as described in <a href="#construct-task-id" class="auto internal xref">Section 3.1</a>.<a href="#section-4-3" class="pilcrow"></a></p>
<p id="section-4-4">The <code>taskprov</code> extension type is defined as follows:<a href="#section-4-4" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-4-5">
<pre>
enum {
taskprov(0xff00),
(65535)
} ExtensionType;
</pre><a href="#section-4-5" class="pilcrow"></a>
</div>
<p id="section-4-6">The extension data in report share for <code>taskprov</code> is zero length, since its
content is transported in "dap-taskprov" header.<a href="#section-4-6" class="pilcrow"></a></p>
</section>
</div>
<div id="leader-behavior">
Expand Down Expand Up @@ -1593,9 +1592,9 @@ <h3 id="name-upload-protocol">
</li>
</ul>
<p id="section-5.1-6">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 <code>task_prov</code> extension type, Leader <span class="bcp14">SHOULD</span> abort the upload request with
"invalidMessage".<a href="#section-5.1-6" class="pilcrow"></a></p>
request as usual.<a href="#section-5.1-6" class="pilcrow"></a></p>
<p id="section-5.1-7">During the upload flow, if Leader's report share does not present a <code>taskprov</code>
extension type, Leader <span class="bcp14">MUST</span> abort the upload request wit "invalidMessage".<a href="#section-5.1-7" class="pilcrow"></a></p>
</section>
</div>
<div id="aggregate-protocol">
Expand All @@ -1617,21 +1616,15 @@ <h3 id="name-collect-protocol">
<p id="section-5.3-1">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 <span class="bcp14">SHOULD</span> also include a "Retry-After" header in its HTTP response
indicating the time after which the Collector should retry its request.<a href="#section-5.3-1" class="pilcrow"></a></p>
so, it is up to the Collector to retry its request.<a href="#section-5.3-1" class="pilcrow"></a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-5.3-2.1">
<p id="section-5.3-2.1.1">TODO: Find RFC reference for "Retry-After".<a href="#section-5.3-2.1.1" class="pilcrow"></a></p>
</li>
</ul>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-5.3-3.1">
<p id="section-5.3-3.1.1">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.<a href="#section-5.3-3.1.1" class="pilcrow"></a></p>
<p id="section-5.3-2.1.1">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.<a href="#section-5.3-2.1.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-5.3-4">The Leader <span class="bcp14">MUST</span> advertise the task in every aggregate share request issued to
the Helper as described in <a href="#definition" class="auto internal xref">Section 3</a>.<a href="#section-5.3-4" class="pilcrow"></a></p>
<p id="section-5.3-3">The Leader <span class="bcp14">MUST</span> advertise the task in every aggregate share request issued to
the Helper as described in <a href="#definition" class="auto internal xref">Section 3</a>.<a href="#section-5.3-3" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down Expand Up @@ -1663,9 +1656,10 @@ <h2 id="name-helper-behavior">
</ul>
<p id="section-6-6">Finally, the Helper completes the aggregate initialize request as usual,
deriving the VDAF verification key for the task as described in
<a href="#vdaf-verify-key" class="auto internal xref">Section 3.2</a>. During the process, if Helper's report share does not
present a <code>task_prov</code> extension type, Helper <span class="bcp14">SHOULD</span> abort the aggregate request
with "invalidMessage".<a href="#section-6-6" class="pilcrow"></a></p>
<a href="#vdaf-verify-key" class="auto internal xref">Section 3.2</a>.<a href="#section-6-6" class="pilcrow"></a></p>
<p id="section-6-7">During Helper aggregate initialization, if Helper's report share does not
present a <code>taskprov</code> extension type, Helper <span class="bcp14">MUST</span> abort the aggregate request
with "invalidMessage".<a href="#section-6-7" class="pilcrow"></a></p>
</section>
</div>
<div id="collector-behavior">
Expand All @@ -1681,8 +1675,7 @@ <h2 id="name-collector-behavior">
described in <a href="#provisioning-a-task" class="auto internal xref">Section 3.3</a>. The Collector <span class="bcp14">MUST</span> advertise the task as
described in <a href="#definition" class="auto internal xref">Section 3</a>.<a href="#section-7-2" class="pilcrow"></a></p>
<p id="section-7-3">If the Leader responds to a collect request with an "unrecognizedTask" error,
but the HTTP response includes a "Retry-After" header, the Collector <span class="bcp14">SHOULD</span>
retry its collect request after waiting for the duration indicated by the
the Collector <span class="bcp14">MAY</span> retry its collect request after waiting for a duration.
header.<a href="#section-7-3" class="pilcrow"></a></p>
</section>
</div>
Expand All @@ -1700,11 +1693,11 @@ <h2 id="name-security-considerations">
and Aggregators have an 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 <code>task_prov</code> extension type in the report
encryption. Furthermore, the presence of <code>taskprov</code> extension type in the report
share means Aggregators that do not recognize Taskprov extension must abort with
<code>invalidMessage</code>, as described in (<span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-07#section-4.4.3" class="relref">Section 4.4.3</a> of [<a href="#DAP" class="cite xref">DAP</a>]</span>). 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.<a href="#section-8-2" class="pilcrow"></a></p>
malicious Author from provisioning a modified task to each party with other
means, which can lead to compromised privacy guarantee in aggregate result.<a href="#section-8-2" class="pilcrow"></a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-8-3.1">
<p id="section-8-3.1.1">OPEN ISSUE: What if the Collector and Aggregators don't agree on the task
Expand Down
69 changes: 34 additions & 35 deletions add-0len-ext-to-report/draft-wang-ppm-dap-taskprov.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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
Expand All @@ -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.

Expand All @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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

Expand All @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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

Expand All @@ -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.
Expand Down

0 comments on commit 8cc4f80

Please sign in to comment.