]> Apple Inc.

shan_wang@apple.com

Cloudflare

chrispatton+ietf@gmail.com

Security Privacy Preserving Measurement next generation unicorn sparkling distributed ledger An extension for the Distributed Aggregation Protocol (DAP) is specified that cryptographically binds the parameters of a task to the task's execution. In particular, when a client includes this extension with its report, the servers will only aggregate the report if all parties agree on the task parameters. This document also specifies an optional mechanism for in-band task provisioning that builds on the report extension. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Privacy Preserving Measurement Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 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 ), how reports are partitioned into batches, and privacy parameters such as the minimum size of each batch. See 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. specifies a report extension () 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 () or the public HPKE configurations 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. specifies one possible mechanism for provisioning DAP tasks that is built on top of the extension in . 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 .

Change Log (RFC EDITOR: Remove this section.) (*) Indicates a change that breaks wire compatibility with the previous draft. 01:

• Add an extension point to the TaskConfig structure and define rules for processing extensions. (*)
• Remove DP mechanisms. (*)
• Add guidelines for extending this document to account for new VDAFs or DAP batch modes. Improve the extension points for these in TaskConfig in order to make this easier. (*)
• Add a salt to the task ID computation. (*)
• Harmonize task lifetime parameters with by adding a task start time and replacing the task end time with a task duration. (*)
• Harmonize batch mode parameters with by removing the deprecated max_batch_query_count and max_batch_size parameters. (*)
• Task provisioning: Remove guidance for per-task HPKE configurations, as this feature was deprecated by DAP.
• Bump draft-ietf-ppm-dap-12 to 13 . (*)
• Bump draft-irtf-cfrg-vdaf-12 to 13 .

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 when, and only when, they appear in all capitals, as shown here. This document uses the same conventions for error handling as . In addition, this document extends the core specification by adding the following error types:

Type	Description
invalidTask	An Aggregator has opted out of the indicated task as described in

The terms used follow those described in . 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 .

The Taskbind Extension To use the Taskbind extension, the Client includes the following extension in the report extensions for each Aggregator as described in : 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 () as follows: where task_config is a TaskConfig structure defined in . Function SHA-256() is as defined in . The task ID is bound to each report share (via HPKE authenticated and associated data, see ). 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 (), 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 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 (), the Leader SHOULD abort the request with "unrecognizedTask" if the derived task ID does not match the task ID of the request.

Task Encoding The task configuration is encoded as follows: ; /* 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; ]]> The purpose of TaskConfig is to define all parameters that are necessary for configuring each party. It includes all parameters listed in as well as two additional fields:

• task_info is an opaque field whose contents are specific to the deployment. For example, this might be a human-readable string describing the purpose of this task.
• extensions is a list of extensions to this document. The format and semantics of extensions are describe in .

This structure does not include cryptographic assets shared by only a subset of the parties, including the secret VDAF verification key or public HPKE configurations . The batch_mode field indicates the DAP batch mode and corresponds to a codepoint in the Batch Modes Registry.

• TODO Add a reference to the IANA registry for batch modes created by .

The batch_config field contains any parameters that are required for configuring the batch mode. For the time-interval and leader-selected batch modes specified in , the payload is empty. Batch modes defined by future documents may specify a non-empty payload; see for details. The length prefix of the batch_config ensures that the batch config can be decoded even if the batch mode is unrecognized. The vdaf_type field indicates the VDAF for the task and corresponds to a codepoint in the VDAF Identifiers registry.

• TODO: Add a reference to the IANA registry created by .

The vadf_config field contains parameters necessary to configure an instance of the VDAF. defines a suitable encoding of the configuration for each VDAF specified in . VDAFs defined by future documents may also use this field as well; see for details. The length prefix of the vdaf_config ensures that VDAF config can be decoded even if the VDAF type is not recognized. The definition of Time, Duration, Url, and BatchMode follow those in .

VDAF config This section defines the payload of TaskConfig.vdaf_config for each VDAF specified in . In some cases, the VDAF supports more than two Aggregators; but since DAP only supports two Aggregators, we do not include the number of Aggregators in the encoding (cf. ).

Prio3Count The payload is empty.

Prio3Sum

Prio3SumVec

Prio3Histogram

Prio3MultihotCountVec

Poplar1

Extensions The TaskConfig structure includes a list of extensions. In general, extensions can be used to bind additional, application-specific information to the task. For example, an extension might be used to encode the identity of the Collector. (Only the Aggregators are identified in TaskConfig.) Each extension is structured as follows: ; } TaskbindExtension; enum { reserved(0), (2^16-1) } TaskbindExtensionType; ]]> The extension_type identifies the extension and extension_data is structured as specified by the extension. Extensions are treated as mandatory-to-implement in the protocol described in . In particular, protocols participants MUST opt-out of tasks containing unrecognized extensions. See . Note that Taskbind extensions are semantically distinct from DAP report extensions and do not share the same codepoint registry (). Future documents may want to define both a Taskbind extension and a report extension, but there may also be situations where a document defines one but not the other.

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

Overview 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 ), 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 Helper during the aggregation protocol (). In particular, it includes the task configuration in an HTTP header of each aggregation job 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.

Task Advertisement To advertise a task to its peer, a protocol participant includes a header "dap-taskprov" with an HTTP request incident to the task execution. The value is the TaskConfig structure defined , expanded into its URL-safe, unpadded Base 64 representation as specified in Sections and of .

Deriving the VDAF Verification Key When a Leader and Helper implement this mechanism, they SHOULD compute the shared VDAF verification key as described in this section. The Aggregators are presumed to have securely exchanged a pre-shared secret out-of-band. The length of this secret MUST be 32 bytes. Let us denote this secret by verify_key_init. Let VERIFY_KEY_SIZE denote the length of the verification key for the VDAF indicated by the task configuration. (See .) The VDAF verification key used for the task is computed as follows: where task_id is as defined in . Functions HKDF-Extract() and HKDF-Expand() are as defined in . Both functions are instantiated with SHA-256() as defined in .

Opting into a Task Prior to participating in a task, each protocol participant must determine if the TaskConfig disseminated by the Author can be configured. The participant is said to "opt in" to the task if the derived task ID (see ) corresponds to an already configured task or the task ID is unrecognized and therefore corresponds to a new task. A protocol participant MAY "opt out" of a task if:

1. The derived task ID corresponds to an already configured task, but the task configuration disseminated by the Author does not match the existing configuration.
2. The VDAF config or other parameters are deemed insufficient for privacy.
3. A secure connection to one or both of the Aggregator endpoints could not be established.
4. The task lifetime is too long.

A protocol participant MUST opt out if:

1. The task has ended.
2. The DAP batch mode or VDAF is not implemented.
3. One of the extensions is not recognized.

The behavior of each protocol participant is determined by whether or not they opt in to a task.

Client Behavior Upon receiving a TaskConfig from the Author, the Client decides whether to opt into the task as described in . If the Client opts out, it MUST NOT attempt to upload reports for the task. Once the client opts into a task, it may begin uploading reports for the task to the Leader. The extension codepoint taskbind 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 . The Client SHOULD advertise the task configuration by specifying the encoded TaskConfig described in in the "dap-taskprov" HTTP header, but MAY choose to omit this header in order to save network bandwidth. However, the Leader may respond with "unrecognizedTask" if it has not been configured with this task. In this case, the Client MUST retry the upload request with the "dap-taskprov" HTTP header.

Leader Behavior

Upload Protocol Upon receiving a Client report, if the Leader does not support the mechanism, it will ignore the "dap-taskprov" HTTP header. In particular, if the task ID is not recognized, then it MUST abort the upload request with "unrecognizedTask". Otherwise, if the Leader does support this mechanism, it first checks if the "dap-taskprov" HTTP header is specified. If not present, that means the Client has skipped task advertisement. If the Leader recognizes the task ID, it will include the client report in the aggregation of that task ID. Otherwise, it MUST abort with "unrecognizedTask". The Client will then retry with the task advertisement. If the Client advertises the task, the Leader checks that the task ID indicated by the upload request matches the task ID derived from the "dap-taskprov" HTTP header as specified in . If the task ID does not match, then the Leader MUST abort with "unrecognizedTask". The Leader then decides whether to opt in to the task as described in . If it opts out, it MUST abort the upload request with "invalidTask". Finally, once the Leader has opted in to the task, it completes the upload request as usual. During the upload flow, if the Leader's report share does not present a taskbind extension type, the Leader MUST abort the upload request with "invalidMessage".

Aggregation Protocol When the Leader opts in to a task, it SHOULD derive the VDAF verification key for that task as described in . The Leader MUST advertise the task to the Helper in every request incident to the task as described in .

Collection Protocol The Collector might create a collection job for a task provisioned by this mechanism prior to opting into the task. In this case, the Leader would need to abort the collect request with "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 this mechanism and those that don't.

The Leader MUST advertise the task in every aggregate share request issued to the Helper as described in .

Helper Behavior The Leader advertises a task to the Helper during each step of an aggregation job and when it requests the Heolper's aggregate share during a collection job. Upon receiving a task advertisement from the Leader, If the Helper does not support this mechanism, it will ignore the "dap-taskprov" HTTP header and process the request as usual. In particular, if the Helper does not recognize the task ID, it MUST abort the request with error "unrecognizedTask". Otherwise, if the Helper supports this mechanism, 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 "invalidMessage". Next, the Helper checks that the task ID indicated in the request matches the task ID derived from the TaskConfig as defined in . If not, the Helper MUST abort with "unrecognizedTask". Next, the Helper decides whether to opt in to the task as described in . If it opts out, it MUST abort the request with "invalidTask". Finally, the Helper completes the request as usual, deriving the VDAF verification key for the task as described in . During an aggregation job, for any report share that does not include the taskbind extension with an empty payload, the Helper MUST mark the report as invalid with error "invalid_message" and reject it.

Collector Behavior Upon receiving a TaskConfig from the Author, the Collector first decides whether to opt into the task as described in . If the Collector opts out, it MUST NOT attempt to initialize collection jobs 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 . The Collector MUST advertise the task as described in . If the Leader responds to a collection request with an "unrecognizedTask" error, the Collector MAY retry its request after waiting an appropriate amount of time.

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 (). The task provisioning mechanism in 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 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 ().

Operational Considerations The Taskbind extension does not introduce any new operational considerations for DAP. The task provisioning mechanism in 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.

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

Report Extension The following entry will be (RFC EDITOR: change "will be" to "has been") added to the "Report Extension Identifiers" registry of the "Distributed Aggregation Protocol (DAP)" page created by :

Value:

0xff00

Name:

taskbind

Reference:

RFC XXXX

Registry for Taskbind Extensions A new registry will be (RFC EDITOR: change "will be" to "has been") created for the "Distributed Aggregation Protocol (DAP)" page called "Taskbind Extensions". This registry contains the following columns:

Value:

The two-byte identifier for the extension

Name:

The name of the extension

Reference:

Where the mechanism is defined

The initial contents of this registry are listed in the following table. Initial contents of the Taskbind Extensions registry.

Value	Name	Reference
0x0000	reserved	of RFC XXXX

DAP Sub-namespace for DAP

• TODO Figure out how to ask IANA to register the errors in . See https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap-taskprov/issues/34

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 ; the registry for VDAFs is defined by ; and the registry for Taskbind extensions is defined in of this document.

Normative References ISRG Cloudflare ISRG Independent Cloudflare There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement (PPM) which can be used to collect aggregate data without revealing any individual user's data. Cisco ISRG Cloudflare Google This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages.

Contributors Junye Chen Apple Inc. junyec@apple.com David Cook ISRG divergentdave@gmail.com Suman Ganta Apple Inc. sganta2@apple.com Gianni Parsa Apple Inc. gianni_parsa@apple.com Michael Scaria Apple Inc. mscaria@apple.com Kunal Talwar Apple Inc. ktalwar@apple.com Christopher A. Wood Cloudflare caw@heapingbits.net