PPM at IETF 113
chairs: Ben Schwartz & Sam Weiler
delegate: Joe Salowey
scribe: Daniel Kahn Gillmor
Intro to PPM (Eric Rescorla)
(presentation)
"Hits" in this presentation should have been "Poplar"
(no critiques, disputes, clarifications, etc from this presentation)
Split uploads and the egress cost problem (Chris Patton)
(presentation)
- blue squares on these slides are aggregators
- leader's special role is tracking the aggregation state across all aggregators
-
inclusion of ingestor introduces new risk (aggregators can withhold or time-shift requests from individual clients, e.g. DoSing them or moving them to a different batch)
-
question about describing the system: can we split out the leader's coordination work from its aggregation work?
- ekr: we could, but then we'd need to define some additional comms channel (or claim it's "magic")
Collect constraint requirements (Chris Wood)
(presentation)
-
Martin Thomson: how does the collector know that there are enough reports in a given window?
- Chris Wood: they can't know without requesting
-
Sam Weiler: how does the system avoid a Sybil attack?
- Chris Wood: that is a separate concern (Sam is not convinced)
-
Stephen Farrell: the use of "space" is unclear here. it could be any dimension!
- Chris Wood: think of it as a bit string
- general uncertainty about what this means. any data packed into "space" may itself be a privacy concern.
Survey of the Cloudflare/ISRG interoperability target (Tim Geoghegan)
(presentation)
- short on time, didn't manage to respond to the questions raised
(presentation)
-
Mariana Raykova: we're not protecting counts, right?
- Alex: yes, server can see counts for each measurement, but the count leaks to the aggregator
-
Ben Schwartz: do you think this fits into the helper/leader/aggregator framework in the PPM draft?
- Alex: i'm not convinced it's a good fit
Open Discussion
- Ben Schwartz: we know that PPM authors want the PPM draft adopted; do STAR authors think that the PPM draft is ready for adoption?
- Chris Patton: do the randomness server and aggregator need to be non-colluding?
- Alex: yes, they must not collude
- Chris Patton: there is a big advantage to aggregators not needing to interact
-
Mariana: I would challenge the statement that the trust models are different
-
ekr: these drafts (STAR and PPM) are not mutually exclusive, we could adopt both
- Martin Thomson: I think the WG should adopt something. i'm convinced that we should adopt the PPM draft, not sure about the STAR draft. I have new concerns about the PPM draft though.
- Ben Kaduk: if we do both, would they be different protocols, or a single protocol which could be implemented with different backends
- ekr: I don't think it's practical to cram STAR in as a VDAF
- Chris Wood: is PPM (which is a wrapper around VDAF) sufficient to abstract away concerns about Poplar (heavy hitters) vs. Prio (counts)? I think PPM is a good framework for this, most of the crypto bits can be stuffed down into the VDAF construction.
- dkg: what is the collusion risk with STAR?
- alex: if randomness server and aggregation server collude (e.g. if the randomness server shares the OPRF key with the aggregator), then the aggregator's attack becomes an offline dictionary attack.
- David Schinazi: i support adopting PPM
- Mariana: we have implemented both Prio and Poplar, and we think PPM is a sufficient framwork for both of them.