Subject: [Ppm] Call for adoption: draft-gpew-priv-ppm-00

From: Samuel Weiler <[email-masked]>
Date: Mon, 4 Apr 2022 11:00:14 -0400 (EDT)

Colleagues,

At IETF113 the chairs heard support for adopting 
draft-gpew-priv-ppm-00 as a PPM WG work item.  Consistent with our 
charter, this does not preclude us adopting additional documents.

Please review the draft to see if you think it is suitable for 
adoption by PPM and send comments to the list no later than 17 April.

For the chairs,

Sam

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Apr 2022 08:36:41 -0700

I am in favor of adoption. Though I believe there is now a -01.

-Ekr

On Mon, Apr 4, 2022 at 8:00 AM Samuel Weiler <[email-masked]> wrote:

> --
> Ppm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppm
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Apr 2022 11:46:04 -0400

I am also in favor of adopting -01
--RLB

---

From: Tim Geoghegan <[email-masked]>
Date: Wed, 6 Apr 2022 09:02:00 -0700

I am in favor of adopting draft-01.

Tim Geoghegan
ISRG

---

From: Erik Taubeneck <[email-masked]>
Date: Wed, 6 Apr 2022 09:20:24 -0700

I am in favor of adopting draft-gpew-priv-ppm-01.

-Erik

---

From: Brandon Pitman <[email-masked]>
Date: Wed, 6 Apr 2022 10:03:19 -0700

Thanks,
Brandon (ISRG)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Apr 2022 04:05:56 +0100

Hiya,

On 04/04/2022 16:00, Samuel Weiler wrote:
> Colleagues,
> 
> At IETF113 the chairs heard support for adopting draft-gpew-priv-ppm-00 
> as a PPM WG work item.  Consistent with our charter, this does not 
> preclude us adopting additional documents.
> 
> Please review the draft to see if you think it is suitable for adoption 
> by PPM and send comments to the list no later than 17 April.

My current answer is "almost, but not quite yet" for the
following reasons:

- On the positive side, draft-grew and the vdaf draft both
seem like fine work, and I'm keen to see them mature, hence
the "almost" however...

- I've no idea what happens if this draft is adopted here but
the vdaf draft is not adopted by cfrg, so maybe we're getting
ahead of ourselves a bit? (That said, I figure the cfrg would
be wrong to not adopt vdaf, but that's not happened afaik and
what do we do if cfrg doesn't?)

- vdaf is IMO too complex - the context here is that we all
ought mistrust clients that ask to do "telemetry" because
there's a decade and more of demonstrated misbehaviour of
clients in that context, so I think we do need a simpler
version of vdaf that can be relatively easily explained to
a random technical person, and I don't think the vdaf draft
is near enough to that yet (it is possible that's a matter
of presentation, but I'm not confident, having just re-read
the vdaf draft)

- I think draft-grew is probably missing an important
requirement: given that mistrusting clients is sensible, I'd
argue ppm needs to include a built-in way for an auditor to
be able to see what aggregate shares result when a set of
clients play the game for a given TaskId - what I mean here
is that if a bit of client s/w is known to support say TaskId
0x0bad1dea, then it ought be relatively easily to setup a
lab configuration where the actual results of that game can
be examined - I don't think that that's envisaged by the
current draft, but I think it's an important goal to try
meet (even if it could be argued to tread a bit over the
line of the WG charter)

That said, if the two requirements below were to be
acceptable to the WG, then I'd be all for adoption:

- suggested r1: it needs to be possible for an auditor
in a lab setting to set themselves up as a collector
for any TaskId known to be supported by a client (it
doesn't have to be trivial and would be entirely fine
if the auditor has to setup aggregators and have fun
with PKI stuff)

- suggested r2: the overall scheme needs to be easy to
explain to someone who is suspicious of the client s/w
(but yeah, "easy" is easy to say, I hope what I mean is
clear enough;-)

I'd argue that both suggested requirements are in line
with the charter as it says "The protocol will be
designed to limit abuse by both client and server,..."
and while I'm not at all fixated on the suggested wording
above for r1/r2, (which I'm sure is imperfect) ISTM meeting
those requirements is likely important in achieving overall
success for the WG.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Apr 2022 16:12:43 -0700

> what do we do if cfrg doesn't?)

Sure. I think it wouldn't be unreasonable to make this draft
acceptance on VDAF acceptance.

> clients in that context,

I don't think this is a really accurate statement of the situation.
Rather, the context here is that under the current system, users
can observe what data is sent via telemetry but not how it is
used. The purpose of PPM is to:

1. Provide clients with confidence in how that data will be used.
2. Allow measurements which would otherwise not be safe
because they would involve collecting sensitive data.

so I think we do need a simpler
> of presentation, but I'm not confident, having just re-read

Given that VDAFs require zero-knowledge proofs to execute
the V part of VDAF, this seems like a pretty unrealistic ask.
I have explained Prio to quite a few people and I never attempt
to explain the ZKP. I just explain the additive secret sharing
and ask them to trust me on the ZKP.

Unless you have an actual algorithm to propose, this seems
equivalent to saying you want this work held indefinitely, which
is contrary to the consensus to charter this group.

> requirement: given that mistrusting clients is sensible,

Again, I think this phrasing is incorrect. The question here is not
trust in the client but trust in the server. It's a basic assumption
that the client is behaving correctly, and if you don't believe that,
then it could be cheating in all sorts of other ways.

> if the auditor has to setup aggregators and have fun

This is perfectly compatible with the existing protocols, and is
merely a question of how the client software actually selects
the aggregator. Given that configuring them is explicitly
out of scope of this WG (by charter) this also seems out of
scope.

> (but yeah, "easy" is easy to say, I hope what I mean is

For the reasons above, I think this is also inappropriate.

-Ekr

---

From: Christopher Patton <[email-masked]>
Date: Thu, 7 Apr 2022 17:05:04 -0700

Hi Stephen!

> what do we do if cfrg doesn't?)

For what it's worth, we've asked the chairs to do an adoption call, but are
still waiting on a response.

> of presentation, but I'm not confident, having just re-read

As far as making the VDAF draft easier to understand, I totally agree --
would love any concrete feedback you may have for improvement! Though
probably best to have this conversation on the CFRG list.

Best,
Chris P.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 8 Apr 2022 01:50:07 +0100

Hiya,

> acceptance on VDAF acceptance.

Right. A bit of clever process-wonkery should sort that,
I agree.

> I don't think this is a really accurate statement of the situation.

I'd assert that that depends on one's perspective.

> 1. Provide clients with confidence in how that data will be used.

I'm not at all sure that's doable, but I wasn't asking
for that. Confidence in what data is visible to a collector
OTOH, yep.

> because they would involve collecting sensitive data.

I fully support that goal.

> and ask them to trust me on the ZKP.

 From my POV that sounds a bit like you're agreeing with me.
The secret-sharing part is easily explained. A scheme that
requires even people who are very good at explaining this
kind of stuff (like yourself and other proponents of this
scheme) ask to be trusted seems to indicate a problem. My
hope is that people clever enough to have developed this
scheme are also able to figure tweaks that make an as-good
variant more easily understood.

> is contrary to the consensus to charter this group.

I really don't want to hold things up and do want to see
progress here, but I worry that if we end up with a scheme
that can't feasibly be explained, the effort won't succeed.
(I don't accept that I need to propose an alternative scheme
for my concern to be valid.)

> then it could be cheating in all sorts of other ways.

Yes, clients can. And there've been many clients that have
demonstrated such misbehaviour, at significant scale.

> This is perfectly compatible with the existing protocols, 

I agree it should be, yes, but I'm asking that we (the WG)
take on board that that auditor role be feasible (in a lab,
probably for an unmodified but specially configured client)
as a requirement for finishing the work.

I don't think that's hard when defining the scheme itself.
I do agree it might be trickier for implementations as it
might imply an ongoing need to publish semantics for TaskIds
or some analogue. (But, maybe that'd be a fine thing?)

I don't expect that this requirement would affect the text
of the spec much, if at all. I do expect that it'd result
in changes as people try to do auditing experiments and I'm
asking that the WG start out with an acceptance that that
kind of input is valid.

> and is

I do agree that defining protocol for runtime selection of
aggregators is out of scope, and what I'm asking here is
similar to, but is not, that.

> For the reasons above, I think this is also inappropriate.

It'd seem pretty odd if "easy to explain" were considered
an anti-goal:-) I fully accept that there will be non-trivial
mechanisms involved (esp for range validation) but I think
we're missing a real requirement if we ignore the problem
that what's going on needs to be understandable to a
relevantly capable experimenter and more-easily explicable to
others.

Cheers,
S.

PS: In response to Chris' mail: yes, CFRG is the better
list for "explaining vdaf" and yes I do plan to try help
there (but I may fail, being comprehensively fallible;-)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Apr 2022 17:59:00 -0700

>  From my POV that sounds a bit like you're agreeing with me.

No.

> variant more easily understood.

Hope isn't a plan.

> for my concern to be valid.)

The question is not whether your concern is valid, but whether
it is in fact practical to design a system of this type which is
readily understandable (as an aside, it seems like it's a
pretty open question whether, for instance, AES or ECC
is actually understandable).

As I said, the WG was chartered to work on this technology,
and it was quite clear at the time that it was cryptographically
complicated. Insisting at this point that it be substantially
less complicated without any demonstration that that is
possible is just relitigating the formation of the group.

> asking that the WG start out with an acceptance that that

As I said, I think this is out of scope for the group.

> an anti-goal:-)

This is not an accurate representation of what I said. I agree
that easy to explain is good; I disagree that it's a requirement.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 8 Apr 2022 02:36:27 +0100

(Eliding bits...)

On 08/04/2022 01:59, Eric Rescorla wrote:
> The question is not whether your concern is valid, 

If we agree it's a valid concern, great. You seemed to
be questioning that.

> but whether
> readily understandable 

Fair point. If it could be demonstrated that no simpler
scheme could do the job, that would be convincing. But I
at least haven't seen such an argument, nor do I recall
that having been part of the chartering process.

> (as an aside, it seems like it's a

My experience is that yes, that's quite doable. And
secret-sharing is even easier. And all that helps.

> possible is just relitigating the formation of the group.

I disagree that that's what I'm suggesting.

>> [... stuff about labs & auditing ...]
> 

Having worked a bit with a colleague (pubs at [1]) who has
had to go to heroic lengths to try figure out what's being
done under the guise of "telemetry" I think we'd be making
a pretty big error in not considering supporting such work
to verify that honest clients are doing as they say.

For sure, aspects of that kind of work are out of scope for
the WG, but making such work practical ought be a thing we
aim to support. If evidence emerges that protocol details
make such work harder, I think the WG needs to take that on
board.

Cheers,
S.

[1] https://www.scss.tcd.ie/Doug.Leith/

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Apr 2022 19:16:23 -0700

I think our respective positions are clear, and I don't believe any useful
purpose
will be served by continuing to engage with you further. I trust the chairs
and
ADs can adequately judge both the relevance of your objections and consensus
on this call for adoption.

-Ekr

---

From: Christopher Wood <[email-masked]>
Date: Wed, 13 Apr 2022 10:00:38 -0700

I am in favor of adopting -01 as the starting point. There’s certainly more work to be done, e.g., sharpening the threat model, dealing with sybil attacks, and so on, but these are challenges that any MPC-like protocol built on the concepts of distributed aggregation and input verification will need to deal with. As such, these are problem that the WG should likely work on.

Best,
Chris

> On Apr 4, 2022, at 8:00 AM, Samuel Weiler <[email-masked]> wrote:
> 
> Colleagues,
> 
> At IETF113 the chairs heard support for adopting draft-gpew-priv-ppm-00 as a PPM WG work item.  Consistent with our charter, this does not preclude us adopting additional documents.
> 
> Please review the draft to see if you think it is suitable for adoption by PPM and send comments to the list no later than 17 April.
> 
> For the chairs,
> 
> Sam
> 
> -- 
> Ppm mailing list
> [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 13 Apr 2022 13:05:04 -0400

I support the adoption of the -01 as a starting point.
Alissa

> On Apr 4, 2022, at 11:00 AM, Samuel Weiler <[email-masked]> wrote:
> 
> Colleagues,
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 14 Apr 2022 07:04:55 +0200

I support adoption.
David

---

From: Christopher Patton <[email-masked]>
Date: Thu, 14 Apr 2022 11:09:27 +0200

I support adoption of -01 as a starting point.

For those who are in favor of taking this draft on, please also consider
having a look at the VDAF draft (
https://datatracker.ietf.org/doc/draft-patton-cfrg-vdaf/) and voicing your
support on the CFRG list.

Chris P.

---

From: Matthew Finkel <[email-masked]>
Date: Fri, 15 Apr 2022 17:17:47 +0000

I also support adoption of -01. Of course, I agree that some of the
sections need more work/filling in, but it seems like a good starting
point.

> I am in favor of adopting -01 as the starting point. There’s certainly
> more work to be done, e.g., sharpening the threat model, dealing with
> sybil attacks, and so on, but these are challenges that any MPC-like
> protocol built on the concepts of distributed aggregation and input
> verification will need to deal with. As such, these are problem that the
> WG should likely work on.
> 
> Best,
> Chris
>