ZIP 0: Security and Privacy Considerations

Governance
1

I’ve submitted a pull request to update ZIP 0, which defines the Zcash Improvement Proposal (ZIP) process. These changes are meant to address gaps in how security and privacy considerations are handled and to bring more clarity and transparency to how proposals are reviewed.

The proposed changes:

  • Make the “Security and Privacy Considerations” section mandatory for all ZIPs
  • Require that ZIPs explicitly document trust assumptions, privacy trade-offs, data leakage risks, and potential attack vectors.
  • Require ZIPs to consider the Wallet Threat Model, and reference or propose updates if applicable
  • Make ZIP authors responsible for obtaining an independent security review of both the design and implementation for high-impact proposals, including formal code review
  • Clarify that ZIP Editors are not expected to perform audits, but must verify that appropriate reviews and documentation are in place.
  • Require Editors to notify the community when a ZIP is submitted as a proposal, to ensure public review and discussion.
  • Strengthen guidance on the Abstract, requiring it to provide a detailed summary of the proposal that highlights key security and privacy considerations.

As I mentioned in the March 20th Arborist Call, the motivation for this change is to address important gaps in the current process around security and privacy review. As it currently stands, ZIP 0 requires a “Security and Privacy Considerations” section if applicable; however, only 2 of the 10 ZIPs being considered for NU7 include this section.

In addition, ZIP 0 also currently fails to clearly define who is responsible for evaluating the security and privacy risks of a proposal. It states that “it is not the primary responsibility of the ZIP Editors to review proposals for security, correctness, or implementability,” but also notes that ZIP editors may reject a proposal if “it has manifest security flaws (including being unrealistically dependent on user vigilance to avoid security weaknesses).” So, the question is who is ultimately responsible for ensuring proper security and privacy analysis?

To be clear, Shielded Labs did not include a “Security and Privacy Considerations” section in the three ZIPs for the NSM. However, we shared the drafts publicly at the same time we submitted them for review, which allowed security concerns to be raised and discussed early in the process. For several of the current ZIPs, it’s unclear whether any public review or formal threat analysis has taken place.

One example I brought up on the Arborist Call is ZIP 231, which introduces variable-length memos. While this change may offer more flexibility for developers, it also introduces the possibility of new privacy leaks due to data-length variation. The ZIP includes no documented discussion of these implications, and in fact, the implementation may violate assumptions in the Wallet Threat Model. My understanding from the discussion at the Arborist Call is that the authors of the ZIP did consider and discuss these privacy and security implications at length, but they were not documented in the ZIP itself.

Again, this is not to pick on ZIP 231, but to illustrate a broader issue with the current process that allows potential security flaws to progress without transparent analysis or community discussion. My hope is that, by making these changes explicit, we can tighten up the process and ensure that proposals with meaningful security or privacy implications are properly reviewed, documented, and discussed.

Please review the PR and let me know if you have any feedback.

5 Likes
3

The ZIP Editors have proposed a number of revisions atop @aquietinvestor’s PR. Please review Update zip-0000.rst by aquietinvestor · Pull Request #1000 · zcash/zips · GitHub

2 Likes
4

First off, a big thank you to the ZIP Editors for the quick turnaround on this. I genuinely appreciate it.

It looks like many of my suggestions were accepted. The new “Privacy Implications” section incorporates much of the language I proposed, including considerations around trust assumptions affecting privacy that are introduced or modified by the proposal; privacy trade-offs or changes to anonymity guarantees; potential data leakage (e.g., from metadata, timing, or usage patterns); and exposure to known or novel privacy attack vectors. It also encourages proposals to consider any relevant threat models and to propose updates where applicable.

The Editors also incorporated the suggestion to require an independent security review by qualified experts for proposals with significant security or privacy implications, which I believe is a meaningful improvement to the process.

I want to take a couple days to review the latest draft more closely, but at first glance, it seems like good progress overall. That said, there are still a few open questions and points of disagreement that I’d like to come back to.

Most notably, there remains a disagreement about the “Privacy Implications” section. I strongly believe it should be mandatory; however, the ZIP Editors have opted to keep it optional. The Editors argue that mandatory sections often result in boilerplate text that adds little value, citing lessons from the RFC process. Instead of making the section required, they added a recommendation that the abstract SHOULD briefly mention any significant privacy implications. The problem is this still leaves it as optional, which is part of the underlying concern.

I believe making the section mandatory is important because it prompts authors to explicitly consider the issue, rather than overlook it. Please recall that ZIP 0 has always included a “Security and Privacy Considerations” section, but because it was optional, it was often ignored. Using SHOULD language is not sufficient. Making the section mandatory creates a clear expectation and gives reviewers and the broader community a concrete signal that privacy implications were considered. Even if a ZIP is not relevant to user privacy, requiring the section allows authors to state that explicitly by including a one-line sentence like, “This proposal has no implications for user privacy.” @earthrise made a similar point stating that requiring the section, even with a minimal statement, creates an objective standard that can be audited, which is much harder to establish if the section is optional or buried in the abstract.

One final question I’d like to raise is about process (more out of general curiosity than because it’s immediately relevant to this discussion): how is it determined what ultimately gets ratified or amended into ZIP 0? Is this solely at the discretion of the ZIP Editors, or is there a defined process for resolving disagreements between individual contributors and the Editors? If a significant portion of the community were to support a change but the Editors disagreed, who would have the final say? Again, I’m not raising this to contest any specific decision, but I’m genuinely interested in how this works and whether it might be helpful to make the process more explicit. I’m also hopeful we can find a reasonable compromise on the points still under discussion.

cc: @daira, @str4d, @nuttycom

5

Hi, Jason,

I’m speaking for myself in my editorial role here, but not for the ZIP Editors as a whole.

The ZIP editors chose to make several changes to increase the importance of the Privacy Implications section. First, it is explicitly stated that the existence of any privacy implications should be included in the abstract. Second, the section has been moved up in the document, with the intention that nontechnical readers of the specification should expect to need to read everything down to the start of the Specification (the Abstract, the Motivation, and the Privacy Implications) in order to get a good idea of the implications of the change. Finally, the absence of a Privacy Implication section has been added as potential grounds for the ZIP Editors to decline to publish a ZIP.

The issue that I personally have with Privacy Implications being a required section is that ZIPs that have no privacy implications, and for which that section would simply be noise, are exceedingly common. Consider the following list:

None of these ZIPs are relevant to topics touching on user privacy; one might argue that the Deployment zips have privacy implications, but these ZIPs are exclusively for the purpose of setting the activation height and consensus branch IDs for deployment of upgrades. A privacy implications section in these ZIPs does not make sense because it is incumbent upon readers to read the privacy implications of the ZIPs actually being deployed in the upgrade, otherwise the deployment ZIPs would need to recapitulate the privacy implications sections in total. I do not believe that it would be appropriate to summarize, because a summary or reference could get out of sync if the privacy implications section of a ZIP being deployed is later updated.

As it stands, I think that the proposed changes will ensure that ZIP privacy implications are clearly documented going forward - and that this is the correct goal; required boilerplate isn’t the best way to achieve that.

I do note that we still need to update the ZIP templates to reflect these changes. That’s actually likely the more impactful thing, in terms of ensuring that privacy implications are stated in appropriate ZIPs.

2 Likes
6

Thanks, Kris. I appreciate your reply and the additional context. I understand your reasoning better now and am okay with keeping it optional for the time being. I agree these changes will go a long way toward improving how privacy implications are documented, which feels like a meaningful step forward.

If the ZIP Editors have time at some point, I’d still be interested in hearing thoughts on the process questions I raised earlier related to ZIP 0.

2 Likes