In-band Task 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 8 January 2024.¶

Copyright Notice

Copyright (c) 2023 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

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. 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 document describes a mechanism designed to fill this gap. Its key feature is that task configuration is performed completely in-band. It relies solely on the upload channel and the metadata carried by reports themselves.¶

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 and Collector) are encoded in an extension field of the Client's report. There is no need for out-of-band task orchestration between Leader and Helpers, therefore making adoption of DAP easier.¶

The extension 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 extension should presume the Author is under the adversary's control. In fact, we expect in a real-world deployment that the Author may be implemented by one of the Aggregators or Collector.¶

Finally, the DAP protocol 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 document 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.¶

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.¶

3. The Taskprov Extension

The process of provisioning a task begins when the Author disseminates the task configuration to the Collector and each of the Clients. When a Client issues an upload request to the Leader (as described in Section 4.3 of [DAP]), it includes in an HTTP header the task configuration it used to generate the report. We refer to this process as "task advertisement". Before consuming the report, the Leader parses the configuration and decides whether to opt-in; if not, the task's execution halts.¶

Otherwise, if the Leader does opt-in, it advertises the task to the Helpers during the aggregate protocol (Section 4.4 of [DAP]). In particular, it includes the task configuration in an HTTP header of its first aggregate request for that task. Before proceeding, the Helper must first parse the configuration and decide whether to opt-in; if not, the task's execution halts.¶

To advertise a task to its peer, a Taskprov participant includes a header "dap-taskprov" with a request incident to the task execution. The value is the TaskConfig structure defined below, expanded into its URL-safe, unpadded Base 64 representation as specified in Sections 5 and 3.2 of [RFC4648].¶

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

    /* A list of URLs relative to which an Aggregator's API endpoints
    can be found. Defined in I-D.draft-ietf-ppm-dap-04. */
    Url aggregator_endpoints<1..2^16-1>;

    /* This determines the query type for batch selection and the
    properties that all batches for this task must have. */
    QueryConfig query_config;

    /* Time up to which Clients are allowed to upload to this task.
    Defined in I-D.draft-ietf-ppm-dap-04. */
    Time task_expiration;

    /* Determines the VDAF type and its config parameters. */
    VdafConfig vdaf_config;
} TaskConfig;

The purpose of TaskConfig is to define all parameters that are necessary for configuring an Aggregator. It includes all the fields to be associated with a task. In addition to the Aggregator endpoints, maximum batch query count, and task expiration, the structure includes an opaque task_info field that is specific to a deployment. For example, this can be a string describing the purpose of this task.¶

The query_config field defines the DAP query configuration used to guide batch selection. It is defined as follows:¶

struct {
    QueryType query_type;         /* I-D.draft-ietf-ppm-dap-04 */
    Duration time_precision;      /* I-D.draft-ietf-ppm-dap-04 */
    uint16 max_batch_query_count; /* I-D.draft-ietf-ppm-dap-04 */
    uint32 min_batch_size;
    select (QueryConfig.query_type) {
        case time_interval: Empty;
        case fixed_size:    uint32 max_batch_size;
    }
} QueryConfig;

The vdaf_config defines the configuration of the VDAF in use for this task. It is structured as follows (codepoints are as defined in [VDAF]):¶

enum {
    prio3_count(0x00000000),
    prio3_sum(0x00000001),
    prio3_histogram(0x00000002),
    poplar1(0x00001000),
    (2^32-1)
} VdafType;

struct {
    DpConfig dp_config;
    VdafType vdaf_type;
    select (VdafConfig.vdaf_type) {
        case prio3_count: Empty;
        case prio3_sum: uint8; /* bit length of the summand */
        case prio3_histogram: uint64<8..2^24-8>; /* buckets */
        case poplar1: uint16; /* bit length of input string */
    }
} VdafConfig;

Apart from the VDAF-specific parameters, this structure includes a mechanism for differential privacy (DP). This field, dp_config, is structured as follows:¶

enum {
    reserved(0), /* Reserved for testing purposes */
    none(1),
    (255)
} DpMechanism;

struct {
    DpMechanism dp_mechanism;
    select (DpConfig.dp_mechanism) {
        case none: Empty;
    }
} DpConfig;

• OPEN ISSUE: Should spell out definition of DpConfig for various differential privacy mechanisms and parameters. See issue #94 for discussion.¶

The definition of Time, Duration, Url, and QueryType follow those in [DAP].¶

task_id = SHA-256(task_config)

verify_key = HKDF-Expand(
    HKDF-Extract(
        task_prov_salt,  # salt
        verify_key_init, # IKM
    ),
    task_id,             # info
    VERIFY_KEY_SIZE,     # L
)

4. Client Behavior

Upon receiving a TaskConfig from the Author, the Client decides whether to opt in to the task as described in Section 3.3. If the Client opts out, it MUST not attempt to upload reports for the task.¶

• OPEN ISSUE: In case of opt-out, would it be useful to specify how to report this to the Author?¶

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. In addition, each report's task ID MUST be computed as described in Section 3.1.¶

5. Leader Behavior

6. Helper Behavior

Upon receiving a task advertisement from the Leader, If the Helper does not support the Taskprov extension, it will ignore the "dap-taskprov" HTTP header and process the aggregate request as usual. In particular, if the Helper does not recognize the task ID, it MUST abort the aggregate request with error "unrecognizedTask". Otherwise, if the Helper supports the extension, it proceeds as follows.¶

First, the Helper attempts to parse payload of the "dap-taskprov" HTTP header. If this step fails, the Helper MUST abort with "unrecognizedMessage".¶

Next, the Helper checks that the task ID indicated in the upload request matches the task ID derived from the TaskConfig as defined in Section 3.1. If not, the Helper MUST abort with "unrecognizedTask".¶

Next, the Helper decides whether to opt in to the task as described in Section 3.3. If it opts out, it MUST abort the aggregate request with "invalidTask".¶

• OPEN ISSUE: In case of opt-out, would it be useful to specify how to report this to the Author?¶

Finally, the Helper completes the aggregate initialize request as usual, deriving the VDAF verification key for the task as described in Section 3.2.¶

7. Collector Behavior

Upon receiving a TaskConfig from the Author, the Collector first decides whether to opt in to the task as described in Section 3.3. If the Collector opts out, it MUST not attempt to upload reports for the task.¶

Otherwise, once opted in, the Collector MAY begin to issue collect requests for the task. The task ID for each request MUST be derived from the TaskConfig as described in Section 3.3. The Collector MUST 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.¶

8. Security Considerations

This document has the same security and privacy considerations as the core DAP specification. In particular, 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.¶

In addition, the Taskprov extension is designed to maintain robustness even when the Author misbehaves, or is merely misconfigured. In particular, if the Clients 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.¶

• OPEN ISSUE: What if the Collector and Aggregators don't agree on the task configuration? Decryption should fail.¶

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.¶

• TODO: Suggest mitigations for this. Perhaps the Aggregators need to keep track of how many tasks in total they are opted in to?¶

9. Operational Considerations

The taskprov extension 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 colletion 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 expires. In particular, Aggregators that operate in this manner MUST NOT opt out once they have opted in.¶

10. IANA Considerations

• NOTE(cjpatton) Eventually we'll have IANA considerations (at the very least we'll need to allocate a codepoint) but we can leave this blank for now.¶

Contributors

• CP: Unless the order is meaningful, consider alphabetizing these names.¶

Junye Chen Apple Inc. [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