PPM (Privacy Preserving Measurements) at IETF 114

Thursday Session 1

Welcome, Administrivia, Agenda Bashing

• For more on the open questions, see:
  https://mailarchive.ietf.org/arch/msg/ppm/J_0i3c8siw9OGihkGpmFoHXT-os/

STAR: Distributed Secret Sharing for Private Threshold Aggregation - Reporting (Shivan Kaul Sahib)

• Note: not adopted as a WG doc
  https://datatracker.ietf.org/doc/html/draft-dss-star
• Central idea: use Shamir secret sharing (see Alex preso from IETF
  113). Need an anonymizing proxy, such as OHAI, and a randomness
  server (masked via OPRF). Implemented in Brave for some telemetry.
• EKR detailed tech Q&A about risks of accepting bad shares and being
  able to reject bogus values; see Apple docs on how they addressed
  this.
• Chairs: might revisit adoption at end of session if there is time.

Distributed Aggregation Protocol for Privacy Preserving Measurement

https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-01

## What's new in DAP-01 (Tim Geoghegan)

• Implementation status: two servers in rust (share common code),
  client in typescript. Needs draft-irtf-cfrg-vdaf, both servers use
  rust prio crate. Interop testing between servers underway. Designing
  interop runner, like quicInteropRunner
• Timestamps are more coarse-grained, have more random bytes.
• Changes to aggregation/leader/jobs to leverage possible
  parallization of preparation.
• Inter-aggregator channel needs mutual auth. Adding DAP-Auth-Token
  header for now, but that requires long-term shared secret and there
  are already many HTTP auth schemes. See slides for survey of channel
  security among parties. What should the doc say about request
  authentication?
• Some goals for next draft: rewrite API to be more resource-oriented,
  better use of HTTP BCPs, revisit authen. Look forward to WG
  discussion. EKR: maybe HTTPAPI WG has advice? Chris Patton: not
  comfortable using HPKE for mutual auth. Rich: caveat that there's
  expertise in HTTPAPI but no current work items. Chris Wood: concern
  that generic auth will be too expensive for traffic, this might not
  be a general protocol after all.
• Discussion of number of helpers involved and communication paths
  between it/them and leader(s). Discussion of power of leader and
  attacks to subvert that.

Use cases / batch selection (Chris Patton)

• https://mailarchive.ietf.org/arch/msg/ppm/NKPIIm5HvZ1p8EkS3tmwj6DBXDs/
• DAP overview presented.
• How to determine set of reports to batch? Need to preserve privacy;
  batch size is app-specific. Currently use time-based intervals. Not
  suited for all uses, such as user-agent or location, or disjoint
  fixed-size batches. So how much more flexibility is needed?
• Proposal: enumerate query types; batch request includes query,
  leader chooses reports that satisfy query. Implementations need not
  support all query types. EKR: we're already off the fairway, let's
  try to solve the full problem (and not worry about overlapping
  issue? I think he said that) What is underlying rule that preserves
  privacy and implement that rule. DKG: the more complicated it is,
  the harder it is for people to know that they're private. Prefer
  not-dynamic group series. CAW: concerned about
  flexibility/protocol-desireability tradeoffs. Wes: need advice
  especially about legal frameworks. ChrisP: agree we should take
  smallest step possible. EKR: drilling down is an important use-case.

Privacy considerations for the collect sub-protocol (Chris Wood)

• https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/195
• Current query has limiting constraints (min batch size, no overlap,
  etc).
• Privacy threat model (not robustness threats): limit malicious
  clients, at least one aggregator is honest, and colllector is
  malicious.
• Enumeration of some attacks and possible mitigations (see slides).
  WG discussion of this.
• (off-topic: ChrisPatton mentioned that CFRG VDAP discussion will be
  touching on differential privacy, seeking knowledgeable people to
  contribute.)
• Is this threat model clear? Any attacks missing? Is selecting
  "intersection attack" something we can mitigate in the protocol?
  EKR: yes, probably, yes. ;) Tim: some of this is in the draft. Nick:
  this is a great start. Audio breakup, see chat for Nick's point
  about multiple parties.

Task Enforcement and Configuration (Shan Wang)

• https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/271,
  https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/290
• Somewhat related to "stuffing attack" from previous. Focusing on
  task parameters here.
• Potential privacy problems (e.g., min batch size) Since parameters
  are out of band, and therefore out of site, can't confirm. Need
  transparency, enforcement by aggregators.
• Presented rationale and example for various points in 271 (see
  slides).
• Taking it futher, doing task configuration in-band (issue 290).
• Replace task-id from a uuid, to (id,parameters) id is a hash.
• Tim: valuable to have dynamic capability to not require three-party
  coordination.
• ChrisP: would like to see a PR, thanks. Shan: will do.
• DKG: How would client be able to evaluate parameters? Seems
  complicated. Helper keeps system honest, having them evaluate is
  hard, might not get helpers. Shan: I think the transparency is
  important.