Subject: Re: [Ppm] Getting ready for 113

From: Tim Geoghegan <[email-masked]>
Date: Thu, 3 Mar 2022 17:15:48 -0800

Hi Ben,

Chrises Patton and Wood (CCed) and myself would like to request 15 minutes
of time during the PPM WG session at IETF 113 to provide an update on what
the draft authors have been up to the months since
draft-gpew-priv-ppm-00[1] was submitted for the BoF at IETF 112. We will
discuss recent changes to the draft (such as revised helper operational
capabilities and asynchronous collect requests) and also introduce some
current open problems that we'd like to discuss with the community (such as
the egress cost problem, ingestion servers and aggregator sync).

Thanks again for chairing!

Tim Geoghegan
ISRG

[1]: https://datatracker.ietf.org/doc/draft-gpew-priv-ppm/

On Mon, Feb 28, 2022 at 7:00 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> Hi PPM,
>
> As I'm sure you've seen, we have 2 hours for our session at IETF 113.
> Please send requests for agenda time!  I think it would be great to repeat
> some of the introductory material from the BoF, and also see how much
> substantive progress we can make.
>
> I believe we're also still looking for a second chair for this group.  If
> you know of someone who might be a good fit, even if they haven't served as
> a working group chair before, please reach out to me or our Area Director
> (Roman Danyliw).
>
> Thanks,
> Ben Schwartz
> PPM WG Chair
> --
> Ppm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppm
>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 4 Mar 2022 10:03:22 -0500

That seems like a lot of material for 15 minutes.  Who will be the primary
speaker?

Since this is the first meeting of the working group, I think it would be
useful to give new participants a chance to come up to speed on the
proposals.  Would anyone like to present an overview?

--Ben

---

From: Tim Geoghegan <[email-masked]>
Date: Fri, 4 Mar 2022 12:50:37 -0800

Chris W. had the same thought. Let's reserve 1 hour then. You can designate
me as the primary speaker.

Thanks,
Tim

On Fri, Mar 4, 2022 at 7:03 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> Chrises Patton and Wood (CCed) and myself would like to request 15
>> minutes of time during the PPM WG session at IETF 113 to provide an update
>> on what the draft authors have been up to the months since
>>> I believe we're also still looking for a second chair for this group.
>>> If you know of someone who might be a good fit, even if they haven't served
>>> as a working group chair before, please reach out to me or our Area
>>> Director (Roman Danyliw).
>>>
>>> Thanks,
>>> Ben Schwartz
>>> PPM WG Chair
>>> --
>>> Ppm mailing list
>>> [email-masked]

---

From: Tim Geoghegan <[email-masked]>
Date: Fri, 4 Mar 2022 13:02:24 -0800

ekr (CCed) has volunteered to re-do his presentation from the IETF 112 BoF.
That was 25 minutes in that meeting's agenda[1] so I think that should be
enough this time around.

Thanks,
Tim

[1]: https://datatracker.ietf.org/doc/agenda-112-priv/

On Fri, Mar 4, 2022 at 12:50 PM Tim Geoghegan <[email-masked]> wrote:

> Chris W. had the same thought. Let's reserve 1 hour then. You can
> designate me as the primary speaker.
>
> Thanks,
> Tim
>
>
>> That seems like a lot of material for 15 minutes.  Who will be the
>> primary speaker?
>>

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Tue, 8 Mar 2022 00:42:54 -0800

Hi Ben, if there's time, we'd like to request 10 minutes to introduce the
draft we just submitted to the datatracker:
https://datatracker.ietf.org/doc/draft-dss-star

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Mar 2022 12:56:03 -0800

Hi Shivan,

Thanks for submitting this draft. It's great to see some other ideas
emerging.

The question I would have is how you envision this fitting into the work of
the group. Do you think we'd try to package it as a VDAF and fit it into
the PPM framework? Or have this be a parallel thing to the PPM framework?

Thanks,
-Ekr

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Wed, 9 Mar 2022 13:26:01 -0800

Hi Ekr, the thought was to have it be parallel to the multi-party PPM
draft. The goals are similar.

On Wed, 9 Mar 2022 at 12:56, Eric Rescorla <[email-masked]> wrote:

> The question I would have is how you envision this fitting into the work
> of the group. Do you think we'd try to package it as a VDAF and fit it into
> On Tue, Mar 8, 2022 at 12:43 AM Shivan Kaul Sahib <
> [email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Mar 2022 22:29:24 +0000

Hi Shivan,

> draft. The goals are similar.

I've no position on this but I do wonder whether having a lot
of difference in the security properties of different schemes
might cause damaging confusion? (Given that we're in a space
where I would expect users to understandably mistrust what
they're told by almost any significant entity.)

For example, in the STAR proposal, I wondered what are the
security properties of the (K+1)-th measurement? (To be
clear though, other than that, I think your scheme is really
nice, esp in being relatively simple to understand/explain,
which may be a v. important attribute here.)

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Mar 2022 09:41:40 +1100

On Thu, Mar 10, 2022, at 09:29, Stephen Farrell wrote:
> security properties of the (K+1)-th measurement? 

I had a similar thought.  If the message is low entropy or the server already knows it, then it seems like this is trivially identifiable via R3.  Also rainbow tables.  The submission via an intermediary helps avoid linkage to a particular event, but then timing might reveal what you were hoping to hide.  It seems like the nature of the message and the constraints under which it is submitted require some more text in the draft.

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Mon, 14 Mar 2022 15:13:57 -0400

Hi Stephen,

> which may be a v. important attribute here.)

Would you mind elaborating what you mean by the "security properties of the
(K+1)th measurement"? Is the concern that after you decrypt the original
measurement you might learn something about the first K measurements if you
kept track of some state for those encrypted measurements (like Martin
implied and I'll respond to), or is it that the (K+1)th measurement is
effectively treated as if it came in unencrypted because the server can
instantly decrypt it? For the latter, the security property that "a server
can only decrypt a measurement if it receives at least K of those values"
still stands and in  combination with the property "a server does not learn
the client identity for ANY submitted measurement via explicit metadata
such as IP address" provided by OHAI/Tor/some sort of oblivious proxy, we
maintain K-anonymity of clients.

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Mon, 14 Mar 2022 15:15:55 -0400

Hi Martin,

On Wed, 9 Mar 2022 at 17:42, Martin Thomson <[email-masked]> wrote:

> I had a similar thought.  If the message is low entropy or the server
> already knows it, then it seems like this is trivially identifiable via
> R3.  Also rainbow tables.  The submission via an intermediary helps avoid
> linkage to a particular event, but then timing might reveal what you were
> hoping to hide.  It seems like the nature of the message and the
> constraints under which it is submitted require some more text in the draft.
>

Would it be helpful to add text saying that a proxy can add random delay to
prevent the server from correlating via timing?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Mar 2022 11:35:35 +0000

Hiya,

On 14/03/2022 19:13, Shivan Kaul Sahib wrote:
> instantly decrypt it? 

Yep. The latter.

> For the latter, the security property that "a server

I guess the once the 1st K measurements have been rx'd then
the server is in a better position to collude with someone
else to perhaps immediately correlate meta-data with the set
of measurements of interest from K+1 on maybe. All fairly
subtle stuff, but again if the main benefit of this scheme
is that it's more easily understood, that might matter.

The draft mentions using time-windows to mitigate that - I
reckon that's something that could be better explained or
maybe made an inherent part of the scheme (with the potential
to lose some measurements if <K happen in a window).

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Mar 2022 11:06:58 +1100

On Tue, Mar 15, 2022, at 06:15, Shivan Kaul Sahib wrote:
> Would it be helpful to add text saying that a proxy can add random 
> delay to prevent the server from correlating via timing?

I think that you might need more than that.  If the timing does reveal information, then yes, delays might be necessary (but the magnitude of the delay becomes an interesting question).  But are there usage contexts where there is no event you are linking to?  For instance, when you submit a report daily at the same time.