IETF 117 Privacy Preserving Measurement Agenda

Monday Session IV, Plaza A

2023 July 24, 17:30 - 18:30 PDT

San Francisco, California, USA

Chairs: Sam Weiler, Ben Schwartz
Area Director: Roman Danyliw

Agenda

1. Administrivia - Chairs (5 min)

2. What's new in DAP-05 - Geoghegan (5 min)

   • Protocol changes since DAP-04
   • Implementation updates.

3. Differential privacy for DAP - Patton (15 min)

   • Overview of options, incl. protocol plumbing in VDAF and DAP

4. Do we need multiple query modes? - Geoghegan (15 min)

   • Consider restricting DAP to just the fixed size query mode.

5. Report Authentication Extension for DAP - Priebe (10 min)

   • Unpublished draft

Meeting Information

• Notes
• Remote Attendance Tool (Meetecho)
• Onsite Tool
• Public Chat (Zulip)
• Public Audio livestream
• Slides

Notes

Tim Geoghegan's DAP-05 presentation

• No questions

Chris Patton's Differential privacy presentation

• Martin: I think this will be scoped to DAP and VDAF. We don't
  deliver on our charter unless some of this is available. This is one
  of the most important parts of the protocol we're building here.
  [Martin supports this being in PPM.]

• EKR: This should not be on the critical path for publishing DAP.

• Chris P: Local DP is a property you get when things fall apart.
  Local DP is not a replacement for DAP.

• Martin: if we're doing central DP, we should have each aggregator
  add noise, which has implications if an aggegrator is malicious. I'm
  keen on having more than one method.

• Watson Ladd: I want to see this here.

• Tim G: Do the concrete bits here. Maybe guidance elsewhere. I think
  DAP shouldn't say anything about local DP - it can be applied
  orthogonally to Prio.

• Shan Wang: local DP alone is not very useful. But coupled with
  aggregation, could be useful.

Tim Geoghegan: Do we need multiple query modes?

• Tim: this is the first time we've broached this, so I'm not looking
  for a decision today. I'd like to hear objections, though.

• EKR: this is incredibly seasonal, so fixed size won't work.

• Martin: I like the idea of polling. Fixed time interval has
  problems. Can't you just ask for what's there now, e.g. ask every
  hour? It's not then time intervals - it would be variable sized
  batching. Bias toward including data in later reports rather than
  lose data. Maybe you have a "disregard older than X" option?

• Kate Hudson: what if you want to compare simultaneous time periods?
  e.g. exactly over a week, count for two different groups.
  Seasonality use case is interesting.

• Chris P: the intention of query types is to allow different ways of
  slicing data. We're asking about constraining them in-band. Give
  collector some control over data. I support this because it
  simplifies - I don't think we need it.

• EKR: the orphaned request comes in two flavors: many systems (e.g.
  Firefox) do not trigger on timestamp in messasge but instead on
  arrival time. The problem you're describing only appears with small
  number of users/reports.

• Tim: my take-aways are to think more about seasonality and whether
  orphaned reports are really a problem.

• Chris P: could we have an interim on this?

• Tim: we should do more work first.

Linmao Song (co-author with Christian Priebe): Report Authentication Extension for DAP

• EKR: why do we need to change DAP?

• Christian: client doesn't directly talk to helper.

• EKR: the threat model doesn't include leader or helper lying.

• Watson Ladd: similar question: in the PPM threat model, we trust the
  leader and helper to assemble resutls - we don't necessarily trust
  the leader and helper to preserve privacy. If we change threat
  model, have to change other things, also.

• Linmao: this doesn't solve for Sybil attacks - client sending many
  reports.

• Tanya Verma: the reuse of token problem is not just an optimization

  • we can use it to track misbehavior over time.

• Linmao: we're trying to prevent attacks on privacy pass
  infrastructure.

• Chris P: We're proposing a WG draft to mitigate Sybil attacks
  without modifying threat model. This draft is a good starting point

  • in the past, we thought an explicit extension in band wasn't
    needed. I like the binding of the token to the report. Privacy Pass
    makes sense here.

• Tim: in this scheme, the helper will extract the token and verify
  it. Where does the helper get the public key to verify the token?

• Linmao: out of band. Contact issuer via a public directory.

• Tim: so a task parameter might be a URL for validation?