Task Binding and In-Band Provisioning for DAP

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 7 May 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

(RFC EDITOR: Remove this paragraph.) This draft is maintained in https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap-taskprov.¶

The DAP protocol [DAP] enables secure aggregation of a set of reports submitted by Clients. This process is centered around a "task" that determines, among other things, the cryptographic scheme to use for the secure computation (a Verifiable Distributed Aggregation Function [VDAF]), how reports are partitioned into batches, and privacy parameters such as the minimum size of each batch. See Section 4.3 of [DAP] for a complete listing.¶

In order to execute a task securely, it is required that all parties agree on all parameters associated with the task. However, the core DAP specification does not specify a mechanism for accomplishing this. In particular, it is possible that the parties successfully aggregate and collect a batch, but some party does not know the parameters that were enforced.¶

A desirable property for DAP to guarantee is that successful execution implies agreement on the task parameters. On the other hand, disagreement between a Client and the Aggregators should prevent reports uploaded by that Client from being processed.¶

Section 3 specifies a report extension (Section 4.4.3 of [DAP]) that endows DAP with this property. First, it specifies an encoding of all task parameters that are relevant to all parties. This excludes cryptographic assets, such as the secret VDAF verification key (Section 5 of [VDAF]) or the public HPKE configurations [RFC9180] of the aggregators or collector. Second, the task ID is computed by hashing the encoded parameters. If a report includes the extension, then each aggregator checks if the task ID was computed properly: if not, it rejects the report. This cryptographic binding of the task to its parameters ensures that the report is only processed if the Client and Aggregator agree on the task parameters.¶

One reason this task-binding property is desirable is that it makes the process by which parties are provisioned with task parameters more robust. This is because misconfiguration of a party would manifest in a server's telemetry as report rejection. This is preferable to failing silently, as misconfiguration could result in privacy loss.¶

Section 4 specifies one possible mechanism for provisioning DAP tasks that is built on top of the extension in Section 3. Its chief design goal is to make task configuration completely in-band, via HTTP request headers. Note that this mechanism is an optional feature of this specification; it is not required to implement the DAP report extension in Section 3.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the same conventions for error handling as [DAP]. In addition, this document extends the core specification by adding the following error types:¶

The terms used follow those described in [DAP]. The following new terms are used:¶

Task configuration:

The non-secret parameters of a task.¶

Task author:

The entity that defines a task's configuration in the provisioning mechanism of Section 4.¶

3. The Taskbind Extension

To use the Taskbind extension, the Client includes the following extension in the report extensions for each Aggregator as described in Section 4.4.3 of [DAP]:¶

enum {
    taskbind(0xff00),
    (2^16-1)
} ExtensionType;

The payload of the extension MUST be empty. If the payload is non-empty, then the Aggregator MUST reject the report.¶

When the client uses the Taskbind extension, it computes the task ID (Section 4.2 of [DAP]) as follows:¶

task_id = SHA-256(SHA-256("dap-taskprov task id") || task_config)

where task_config is a TaskConfig structure defined in Section 3.1. Function SHA-256() is as defined in [SHS].¶

The task ID is bound to each report share (via HPKE authenticated and associated data, see Section 4.4.2 of [DAP]). Binding the parameters to the ID this way ensures, in turn, that the report is only aggregated if the Client and Aggregator agree on the parameters. This is accomplished by the Aggregator behavior below.¶

During aggregation (Section 4.6 of [DAP]), each Aggregator processes a report with the Taskbind extension as follows.¶

First, it looks up the ID and parameters associated with the task. Note the task has already been configured; otherwise the Aggregator would have already aborted the request due to not recognizing the task.¶

Next, the Aggregator encodes the parameters as a TaskConfig defined in Section 3.1 and computes the task ID as above. If the derived task ID does not match the task ID of the request, then it MUST reject the report with error "invalid_message".¶

During the upload flow (Section 4.4 of [DAP]), the Leader SHOULD abort the request with "unrecognizedTask" if the derived task ID does not match the task ID of the request.¶

uint32 VdafType; /* As defined in Section 10 of [VDAF] */

struct {
    /* Info specific for a task. */
    opaque task_info<1..2^8-1>;

    /* Leader API endpoint. */
    Url leader_aggregator_endpoint;

    /* Helper API endpoint. */
    Url helper_aggregator_endpoint;

    /* Time precision. */
    Duration time_precision;

    /* Minimum batch size. */
    uint32 min_batch_size;

    /* The batch mode and its parameters. */
    BatchMode batch_mode;
    opaque batch_config<1..2^16-1>;

    /* The earliest timestamp that will be accepted for this task. */
       task. */
    Time task_start;

    /* The duration of the task. */
    Duration task_duration;

    /* Determines the VDAF type and its config parameters. */
    VdafType vdaf_type;
    opaque vdaf_config<1..2^16-1>;

    /* Taskbind Extensions. */
    TaskbindExtension extensions<0..2^16-1>;
} TaskConfig;

struct {
    uint32 max_measurement; /* largest summand */
} Prio3SumConfig;

struct {
    uint32 length;       /* length of the vector */
    uint8 bits;          /* bit length of each summand */
    uint32 chunk_length; /* size of each proof chunk */
} Prio3SumVecConfig;

struct {
    uint32 length;       /* number of buckets */
    uint32 chunk_length; /* size of each proof chunk */
} Prio3HistogramConfig;

struct {
    uint32 length;       /* length of the vector */
    uint32 chunk_length; /* size of each proof chunk */
    uint32 max_weight;   /* largest vector weight /
} Prio3MultihotCountVecConfig;

struct {
    uint16 bits; /* bit length of the input string */
} Poplar1Config;

struct {
  TaskbindExtensionType extension_type;
  opaque extension_data<0..2^16-1>;
} TaskbindExtension;

enum {
  reserved(0),
  (2^16-1)
} TaskbindExtensionType;

4. In-band Task Provisioning with the Taskbind Extension

Before a task can be executed, it is necessary to first provision the Clients, Aggregators, and Collector with the task's configuration. The core DAP specification does not define a mechanism for provisioning tasks. This section describes a mechanism whose key feature is that task configuration is performed completely in-band, via HTTP request headers.¶

This method presumes the existence of a logical "task author" (written as "Author" hereafter) who is capable of pushing configurations to Clients. All parameters required by downstream entities (the Aggregators) are carried by HTTP headers piggy-backed on the protocol flow.¶

This mechanism is designed with the same security and privacy considerations of the core DAP protocol. The Author is not regarded as a trusted third party: it is incumbent on all protocol participants to verify the task configuration disseminated by the Author and opt-out if the parameters are deemed insufficient for privacy. In particular, adopters of this mechanism should presume the Author is under the adversary's control. In fact, we expect in a real-world deployment that the Author may be co-located with the Collector.¶

The DAP protocol also requires configuring the entities with a variety of assets that are not task-specific, but are important for establishing Client-Aggregator, Collector-Aggregator, and Aggregator-Aggregator relationships. These include:¶

• The Collector's HPKE [RFC9180] configuration used by the Aggregators to encrypt aggregate shares.¶

• Any assets required for authenticating HTTP requests.¶

This section does not specify a mechanism for provisioning these assets; as in the core DAP protocol; these are presumed to be configured out-of-band.¶

Note that we consider the VDAF verification key [VDAF], used by the Aggregators to aggregate reports, to be a task-specific asset. This document specifies how to derive this key for a given task from a pre-shared secret, which in turn is presumed to be configured out-of-band.¶

verify_key = HKDF-Expand(
    HKDF-Extract(
        SHA-256("dap-taskprov"), # salt
        verify_key_init,         # IKM
    ),
    task_id,                     # info
    VERIFY_KEY_SIZE,             # L
)

5. Security Considerations

The Taskbind extension has the same security and privacy considerations as the core DAP protocol. In addition, successful execution of a DAP task implies agreement on the task configuration. This is provided by binding the parameters to the task ID, which in turn is bound to each report uploaded for a task. Furthermore, inclusion of the Taskbind extension in the report means Aggregators that do not implement this extension will reject the report as required by (Section 4.5.3 of [DAP]).¶

The task provisioning mechanism in Section 4 extends the threat model of DAP by including a new logical role, called the Author. The Author is responsible for configuring Clients prior to task execution. For privacy we consider the Author to be under control of the adversary. It is therefore incumbent on protocol participants to verify the privacy parameters of a task before opting in.¶

Another risk is that the Author could configure a unique task to fingerprint a Client. Although Client anonymization is not guaranteed by DAP, some systems built on top of DAP may hope to achieve this property by using a proxy server with Oblivious HTTP [RFC9458] to forward Client reports to the Leader. If the Author colludes with the Leader, the attacker can learn some metadata information about the Client, e.g., the Client IP, user agent string, which may deanonymize the Client. However, even if the Author succeeds in doing so, the Author should learn nothing other than the fact that the Client has uploaded a report, assuming the Client has verified the privacy parameters of the task before opting into it. For example, if a task is uniquely configured for the Client, the Client can enforce the minimum batch size is strictly more than 1.¶

Another risk for the Aggregators is that a malicious coalition of Clients might attempt to pollute an Aggregator's long-term storage by uploading reports for many (thousands or perhaps millions) of distinct tasks. While this does not directly impact tasks used by honest Clients, it does present a Denial-of-Service risk for the Aggregators themselves. This can be mitigated by limiting the rate at which new tasks are configured. In addition, deployments SHOULD arrange for the Author to digitally sign the task configuration so that Clients cannot forge task creation, e.g., via an extension to Taskbind (Section 3.3).¶

6. Operational Considerations

The Taskbind extension does not introduce any new operational considerations for DAP.¶

The task provisioning mechanism in Section 4 is designed so that the Aggregators do not need to store individual task configurations long-term. Because the task configuration is advertised in each request in the upload, aggregation, and collection protocols, the process of opting-in and deriving the task ID and VDAF verify key can be re-run on the fly for each request. This is useful if a large number of concurrent tasks are expected. Once an Aggregator has opted-in to a task, the expectation is that the task is supported until it ends. In particular, Aggregators that operate in this manner MUST NOT opt out once they have opted in.¶

7. IANA Considerations

This document requests a codepoint for the taskbind report extension and for creation of a new registry for Taskbind extensions.¶

(RFC EDITOR: Replace "XXXX" with the RFC number assigned to this document.)¶

8. Extending this Document

The behavior of the taskbind extension may be extended by future documents that define:¶

1. A new DAP batch mode¶

2. A new VDAF¶

3. A new Taskbind extension¶

Documents defining either a new DAP batch mode or VDAF SHOULD include a section titled "Taskbind Considerations" that specifies the payload of TaskConfig.batch_config or TaskConfig.vdaf_config respectively.¶

Note that the registry for batch modes is defined by [DAP]; the registry for VDAFs is defined by [VDAF]; and the registry for Taskbind extensions is defined in Section 7.2 of this document.¶

9. Normative References

[DAP]

Geoghegan, T., Patton, C., Pitman, B., Rescorla, E., and C. A. Wood, "Distributed Aggregation Protocol for Privacy Preserving Measurement", Work in Progress, Internet-Draft, draft-ietf-ppm-dap-13, 2 November 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-13>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9180]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

[RFC9458]

Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, DOI 10.17487/RFC9458, January 2024, <https://www.rfc-editor.org/rfc/rfc9458>.

[SHS]

"Secure Hash Standard", FIPS PUB 180-4 , 4 August 2015.

[VDAF]

Barnes, R., Cook, D., Patton, C., and P. Schoppmann, "Verifiable Distributed Aggregation Functions", Work in Progress, Internet-Draft, draft-irtf-cfrg-vdaf-13, 2 November 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vdaf-13>.

Contributors

Junye Chen Apple Inc. [email protected]¶

David Cook ISRG [email protected]¶

Suman Ganta Apple Inc. [email protected]¶

Gianni Parsa Apple Inc. [email protected]¶

Michael Scaria Apple Inc. [email protected]¶

Kunal Talwar Apple Inc. [email protected]¶

Christopher A. Wood Cloudflare [email protected]¶

Authors' Addresses