PPM interim 2025-03-11

Notes by Chris P./Tim G.

DAP feature set (Chris Patton)

https://datatracker.ietf.org/meeting/interim-2025-ppm-01/materials/slides-interim-2025-ppm-01-sessa-dap-feature-set-00

Will cover the desired feature set of DAP and extensibility of it in the
future.
Initial use cases (from the BoF) where all about client-side telemetry

• use cases like ENPA (2020) or Firefox Prio experiments back in ~2018

Post-BoF new use cases emerge:

• federated machine learning
• private ad conversion measurement at W3C (PATCG/PATWG)

DAP's job is to privately compute some aggregation function over a set
of measurements

• sometimes "refined" using an "aggregation parameter"
• agg_result = F(agg_param, meas_1, meas_2, ..., meas_n)

DAP solves this using a 2 party MPC

• privacy holds if >1 aggregator is honest
  DAP is three interactions:
• clients upload reports to leader
• leader aggregates reports with the helper
• collector collects aggregate results from aggregators (via
  leader)

A task captures configuration of an instance of DAP

• what VDAF is being run
• identities of some participants
• various secrets
  Security goals:

• securely execute VDAF

  • privacy if >1 aggregator is honest
  • leader and collector are frequently same entity
  • robustness against bogus measurements

• task agreement

  • agreement on task ID, but negotiation + distribution of task
    parameters is out of scope of DAP

• replay protection
  Non goals:

• differential privacy
• Sybil attack resistance
  • Injection of lots of data to affect privacy goals

Extension of DAP:

• DAP is compatible with a class of VDAF

  • Right now we have Prio3 family
  • PINE adapted for federated learning
  • Mastic for attribute based aggregation, approximate heavy
    hitters
  • New VDAFs can be defined in the future to solve new problems

• New batch modes

  • DAP comes with time interval and leader selected batch modes
  • DAP has extension points for new batch modes

• Report extensions

  • Clients can add more info to uploaded reports
  • taskprov/bind to grant hope that everyone agrees on task params
  • reportauth for sticking Privacy Pass token in a report
  • differential privacy budget parameters

• Extensions to HTTP API

  • New HTTP routes
  • e.g. draft-dcook-ppm-dap-interop-test-design for automating
    interop testing

Features we aren't using yet:

• Maybe stuff we could take out

• Multi-step/round VDAFs

  • Prio3, Mastic, PINE are all single-round
  • Chris sez we should keep it because arithmetic sketching might
    have really neat applications
  • Tim also thinks we should keep this, and reckons implementations
    can just not implement multi-round VDAFs if they don't want them

• Aggregation parameter

  • Not used by Prio3 or PINE, Mastic does have it
  • Chris sez we should keep it
  • Tim also thinks we should keep this

• Batch modes

  • Technically leader selected covers all possible use cases, since
    it lets leader construct arbitrary batches

Rejected features:

• secure aggregation beyond VDAFs

  • general purpose MPC (too slow)

• multiple helpers (aka >2 aggregators)

  • weaker trust model, but too hard to implement or specify

• multiple collections of the same batch

  • varying aggregation parameter
  • needed for heavy hitters via Poplar1/Mastic
  • too much protocol complexity, privacy leaks we can't fix

• batched preparation

  • as in Whisper

    • | https://eprint.iacr.org/2024/666 | | https://mailarchive.ietf.org/arch/msg/ppm/ztWYtmiWBz0RrHKL__4pVeGZgdM/ |

  • could be done in a future draft that defines an alternate
    aggregation API, plus maybe a batch mode

Aligning DAP with RFC 9205 / BCP 56 (Tim)

• RFC 9205: Building protocols on top of HTTP (BCP 56 is about
  protocols in general)

• Recent changes to DAP

  • Catch up to latest VDAF draft

  • Async aggregation

    • Why? To reduce burden on Helper observed in prod: HTTP
      requests shouldn't take too long
      • High computation (big histograms)
      • Resource contention (waiting to read/write to a row in a
        DB)

  • Align collection job handling logic/ aggregation job handling

• Goals:

  • There are some guidelines from 9205 that we should follow

    • Tim: I plan to do PRs to do just that
      • Editorial changes to the draft; HTTP error codes (no
        other changes)

  • Long-running operations need polishing

    • E.g., agg share request is synchronous, but a reader might
      expect it to be asynchronous given that every other
      interaction is asynchronous

  • Potentially change wire formats

• Observations from aggregation job step

  • status code is 200 specific

    • Ben Schwartz: 9205 is telling us that the server is free to
      choose between 200 and 201
      • Tim G.: yes. let's also look at the ACME RFC for
        inspiration

  • response body contains an enum discriminant, which you use to
    tell whether the job is processing or ready

    • empty response body is sufficient

• Collection jobs

  • Same observations as for aggregation jobs
  • Forbid sync, but aggregation jobs might be sync

• Aggregate share request

  • Forbid async (opposite problem as collection jobs!)

• In summary, we need:

  • to change response codes
  • to distinguish "ready" from "processing" with an empty response
    body
  • A consistent semantic for long-running operations
    • Follow CRUD (Create, Read, Update, Delete)
    • We don't need asynchronous upload

• Proposed changes

  • aggregation: tweak HTTP status codes and message formats

  • agg share:

    • Add async mode
    • Require an identifier for "agg share ID"

  • collection: add async mode

• When responding to a request, you get to choose whether to handle
  synchronously or asynchronously.

• Discussion

  • Ben S.: Let's repeat HTTPDIR review after this process

    • Tim G.: agree, but there a couple of design decisions we've
      made that we think are right and they might disagree with.
      • Ben S.: Let's not assume that we're going to be told to
        make those changes.

  • Chris P.: I'm on board, but we should check with implementers to
    see if they're willing to implement these changes.

  • Tim G.: My next step is to catch up on ACME and learn from their
    experience

DAP bulk uploads (Alex K.)

• PPA (W3C): Proposal to use DAP for measuring ad campaigns
• Involves an intermediary between clients and leader
• Intermediary has millions of reports it wants to upload

• two design questions:

  • should this be its own draft or in the core protocol
  • how to deal with "partial failures"? Request may fail while the
    Leader is ingesting the data (could be gigabytes!)

• Discussion

  • Tim G.:

    • I support doing this in DAP. The main question is timing.
    • Let's also try to merge "bulk upload" and "upload" into one
      API
    • What to do about partial failures
      • Alex:
        • There is an HTTP proposal related to resuming
          uploads that we might be able to adopt
        • https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/06/
        • For normal rejections ...

  • Chris P.:

    • Let's consider adopting async semantics, like collection or
      aggregation flows

    • Not sure we should way on resumable upload getting
      implemented

      • Alex K.: It might be nice to allow the client to upload
        one stream

    • If we take this in DAP, then I agree let's merge the APIs

  • Ben S.:

    • resumable upload is higher complexity than we need
    • question about atomicity: it's going to be important for
      each uploaded batch to be acknowledged (or rejected)
      • this probably means you can't process in a streaming
        fashion
        • this probably means you need to agree on a maximize
          size

  • Tim: Let's look at AWS S3 for inspiration

    • Alex K.: This API is too heavy weight for this use case
      • Ben S.: Agree.

ECDH-PSI (wangyuchen)

• Implemented by industry

  • PrivateID - Meta
  • PETAce - TikTok
  • Private Join / Compute - Google
  • secretflow-PSI - Ant Group
  • Matching between different internal offices (US DoE)
  • Detecting leaked passwords (Microsoft)
  • CSAM (Apple)
  • Match tax code (Bank of Italy, ISTAT)
  • Official UN statistics (UN)

• Use cases

  • Determine cardinality / intersection for common customers w/o
    sharing data directly

    • join marketing, finding dormant credit card users, blocklist
      matching

  • Adopted in China: Taobao, Alipay, Bytedance, China Unionpay

• Stems from Meadows86 w/ EC parameters

  • Records converted to points on curve, then masked by secret keys
    of both parties with scalar multiplication
  • If r_a = r_b they match the same point

• Security model

  • Semi-honest model, often considered secure
  • Looked at malicious model

  • Using masked message in one session to another session

    • TLS channel binding mitigates

  • Using KDF to truncate the binary rep of EC points

  • Quantum:

    • Ben Schwartz: Is it subject to post-collection decryption?
    • Wang Yu Chen: Yes

  • Deb (AD): Given wide industry use, why does this need a new
    standard?

    • Wang Yu Chen: Existing implementations are not
      interoperable.