Update security considerations

[cjpatton]

Closes #211.

This change is primarily editorial and includes the following changes:

• Replace references to "Prio" with references to a generic VDAF. (This
  section was written long ago when we had Prio in mind.)
• Elaborate on known issues for collect requests.
• Discuss Sybil attacks, including enumerating the different types
  (Sybil attack distinction #211).

[tgeoghegan]

Does "core" mean a deployment that doesn't use report extensions or any kind of client authentication mechanism?

[csharrison]

Beyond the protocol extensions it is also the case that some VDAFs have Sybil protections (against privacy) built-in e.g. with noise addition / differential privacy. DAP could enforce that the aggregation function provide this kind of privacy but we choose not to.

[cjpatton]

@tgeoghegan "core" refers to the bits of the spec that apply to all implementations. In particular, not every implementation will be required to interpret extensions the same way.

@csharrison It's not clear to me that DP always provides adequate protection against Sybil attacks. I think it ultimately depends on how you define privacy. That said, requiring DP is totally on the table, but before doing this I think we should start by spelling out what this would look like as an optional feature of the protocol. I think the first question to ask is whether this mechanism lives here or in the underlying VDAF. I would love to have your help on this.

[csharrison]

@csharrison It's not clear to me that DP always provides adequate protection against Sybil attacks. I think it ultimately depends on how you define privacy. That said, requiring DP is totally on the table, but before doing this I think we should start by spelling out what this would look like as an optional feature of the protocol. I think the first question to ask is whether this mechanism lives here or in the underlying VDAF. I would love to have your help on this.

I think if you can prove that the system achieves user-level DP you should be able to show that even with worst-case Sybil attacks, a user's privacy is still protected to some degree. That being said, this is a property of the whole system, not just the VDAF.

I am fairly sure that DAP / PPM does not want to require DP in its deployments. This brings on a lot of baggage, and for instances where these kinds of attacks are truly not a problem (e.g. with airtight client authentication) it might not be that useful. The main point here is that we might want to call out that the particular VDAF used may mitigate some of the risks of Sybil.

[cjpatton]

If achievable, I think specifying an optional, generic DP mechanism here (perhaps for some class of VDAFs with a specific property) would have significant advantages. IIUC, tuning and enforcing the privacy budget will require knowledge of how measurements are generated by clients over time. This is something that will be dictated by the deployment, and I think it would be best to avoid bleeding deployment details into VDAF wherever possible.

That said, VDAF may need to at least say something about how/when to add noise into an input or aggregate share.

[csharrison]

If achievable, I think specifying an optional, generic DP mechanism here (perhaps for some class of VDAFs with a specific property) would have significant advantages

I think this is possible. We can probably have some tunable, exposed property of a VDAF that is a necessary but not sufficient condition for achieving DP. We can describe the rest of the conditions needed in the DAP deployment to get the rest of the way there.

This will not be super easy to do, but I am happy to help think through what it will take (maybe in a separate issue).

[cjpatton]

Kicking off an issue is probably a good way forward. I'm happy to help with the protocol design, but will need to lean on you to make sure we have all the plumbing we need to implement. A couple seed questions to start:

1. Who adds noise and when? Do we want to support local DP, centralized DP, or both? Also would be helpful to define these (and point to references where needed).
2. What syntactic changes are necessary for VDAF?

Once you create the issue, it would also be helpful to ping the list with a brief description of the issue and a link.

[csharrison]

commented on #19, I doesn't answer all the questions but it's a start :)

[chris-wood]

The list of attacks is really a list of things we ought to fix in the protocol, so I would not even bother including them in the security considerations. If we want to use this as an opportunity to identify open issues that need to be addressed before we consider the protocol secure, I would simply list the open issues and keep discussion in GitHub. (That is, the text here seems redundant with the issue 🤷 )