CPS-???? | Governance Security #490
Conversation
This is the initial commit for the governance security CIP based on discussions at the Longmont Voltaire CIP-1694 Working Group.
correct the format for spacing
Added the correct authors
Posted the pull request discussion link to the discussion section of the header.
Correct typos in the abstract Co-authored-by: Adam Dean <63186174+Crypto2099@users.noreply.github.com>
Added threat number 1 to the Specification section to begin the process.
|
Notifying @AndrewWestberg @Quantumplation @mmahut @Chris-Graffagnino @JamesRobertKelley @hashedbits that this pull request has been started for the Cardano Governance Security CIP. Need to add more people for public comment and review of this CIP. |
Added an initial list of governance threats for public review, comment, input, and feedback.
Brackets not needed. N/A until responses are received. Co-authored-by: Adam Dean <63186174+Crypto2099@users.noreply.github.com>
|
If this isn't about a specific technical solution (metadata standard, change to the ledger rules, etc.), does it make more sense as a "Cardano Problem Statement" (CPS)? Other than that, it's looking great so far! Thanks for leading this charge :) |
There was a problem hiding this comment.
@rickymac68 @AndrewWestberg this is a great checklist of design issues but it is unreviewable as a CIP as already mentioned here:
#490 (comment)
#490 (comment)
Therefore we also need to retitle this PR as a CPS immediately so the rest of the discussion can proceed properly. So far the reviews & recommended changes are cosmetic, but when the conceptual reviews come in they should go into the CPS framework so each of the items on your checklist might suggest a corresponding CIP with practical content.
Please see here why the CPS was created to house multiple CIPs with common context and goals: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999#motivation-why-is-this-cip-necessary
The CPS outline also has an explicit Goals section which would therefore contain the 25 items currently listed in your Specification section (which currently contains no specifications for any of these items.. while their corresponding CIPs would).
The rest of this content could be slotted into these sections in the CPS template and then we would have a CPS properly set up for review: https://github.com/cardano-foundation/CIPs/blob/master/.github/CPS-TEMPLATE.md
|
@rickymac68 now that your tweet (https://twitter.com/RichardMcCrackn/status/1640532025475047426) has attracted a small army of spell correctors (the latest of these creating a GitHub account just for this purpose), submitting review after review with insubstantial comments unrelated to the proposal substance, I believe the best thing to do is:
I've attempted to stem the tide here (https://twitter.com/COSDpool/status/1640682163023511552) but it appears to be having no effect. Maybe a Twitter announcement of your own would help to keep things clean in this repository, and avoid propagating the false idea that GitHub is to be used as a group editing scratch-pad (an alternative that works well = https://hackmd.io) |
|
I agree, please @rickymac68 can this be amended asap. |
|
Hi Robert,
In no means as experienced in reviewing as you are and not as knowledgeable
in the subject matter. Maybe you can explain to me what it means to create
a CPS pull request after closing the PR.
Meanwhile I mean to find ways to contribute in a positive way and I will
keep learning all the way.
Greetings, Marco
Op di 28 mrt. 2023 20:38 schreef Robert Phair ***@***.***>:
… @rickymac68 <https://github.com/rickymac68> now that your tweet (
https://twitter.com/RichardMcCrackn/status/1640532025475047426) has
attracted a small army of spell correctors (the latest of these creating a
GitHub account just for this purpose), submitting review after review with
insubstantial comments unrelated to the proposal substance, I believe the
best thing to do is:
1. correct the accumulated spelling mistakes offline
2. then re-submit this document as a CPS pull request
<#490 (review)>
after closing this PR.
I've attempted to stem the tide here (
https://twitter.com/COSDpool/status/1640682163023511552) but it appears
to be having no effect. Maybe an announcement of your own would help to
keep things clean in this repository, and avoid propagating the false idea
that GitHub is to be used as a commenting scratch-pad (an alternative that
works well = https://hackmd.io)
cc @AndrewWestberg <https://github.com/AndrewWestberg> @KtorZ
<https://github.com/KtorZ> @Ryun1 <https://github.com/Ryun1>
—
Reply to this email directly, view it on GitHub
<#490 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A6ZY2AXEBEWPNW2BXUMJUL3W6MV2NANCNFSM6AAAAAAWJW7NKY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@CIP-review (Marco), my last comment was addressed to one of the authors (you can see this by following the @ tags). So there is nothing for you do to except (along with the 56,900 people invited by @rickymac68 to post here in GitHub, even without any prior experience) please abstain from making comments here until that invitation is retracted and a proper version of this proposal is finally published in a different thread. No need to respond to this posting either. |
|
Understood, let me know when it is usefull to contribute. My mistake. |
better description Co-authored-by: Adam Dean <63186174+Crypto2099@users.noreply.github.com>
spelling errors Co-authored-by: Jane14457995 <90640701+Jane14457995@users.noreply.github.com>
CPS is the correct category Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
All sections need to be demoted to H2 Co-authored-by: Robert Phair <rphair@cosd.com>
Change specification to goals and demote to H2 Co-authored-by: Robert Phair <rphair@cosd.com>
Improved description the CPS intent Co-authored-by: Shaneeljiv <49743809+Shaneeljiv@users.noreply.github.com>
Co-authored-by: CIP-review <129207554+CIP-review@users.noreply.github.com>
Batch of multiple typo corrections Co-authored-by: jungmyeonghan <55140432+jungmyeong96@users.noreply.github.com> Co-authored-by: CIP-review <129207554+CIP-review@users.noreply.github.com>
Sure Robert. Can you tell me what I need to do to get it sorted? I'm thinking of just accepting all the valid changes so far, then I can copy and paste it into a new folder /CPS-???/README.md I would like to preserve the comment history if I can. p.s. I kinda suck at GitHub, need explicit instructions. |
Demoted remaining sections to H2
Motivation to H2
Ok, I'll do it this way @rphair thanks for guidance. |
|
|
||
| ### #1: Unknown software vulnerability affecting governance is discovered. | ||
|
|
||
| Recommendation: The person discovering the vulnerability should document the circumstances and details in which the vulnerability is present and how to reproduce the vulnerability. Then report the vulnerability in a confidential manner using a secure method to the developer team with the resources to correct the vulnerability. |
There was a problem hiding this comment.
The last part "with the resources to correct the vulnerability" may not be known to the person that highlights the vulnerability. It can be optional.
| Recommendation: The person discovering the vulnerability should document the circumstances and details in which the vulnerability is present and how to reproduce the vulnerability. Then report the vulnerability in a confidential manner using a secure method to the developer team with the resources to correct the vulnerability. | ||
|
|
||
| ### #2: Emergency group to support the disaster recovery plan. | ||
| -attacks on persons if known |
There was a problem hiding this comment.
I think "exposes the person(s) if known" is better. It is efficient to focus our resources in forward thinking than retribution. If at the end, some people want to take that extra step, anyone can certainly do so.
|
|
||
| ### #1: Unknown software vulnerability affecting governance is discovered. | ||
|
|
||
| Recommendation: The person discovering the vulnerability should document the circumstances and details in which the vulnerability is present and how to reproduce the vulnerability. Then report the vulnerability in a confidential manner using a secure method to the developer team with the resources to correct the vulnerability. |
There was a problem hiding this comment.
The person discovering the vulnerability should document the circumstances and details in which the vulnerability is present and how to reproduce the vulnerability. The vulnerability should then be reported in a confidential manner using a secure method to the developer team. If the fix is known, the person can propose approaches/resources to correct the vulnerability
|
|
||
| ### #5: Committee keys lost or stolen or committee keys sold to a bad actor. | ||
|
|
||
| Recommendation: |
There was a problem hiding this comment.
- Keys should be held in a decentralized manner so that one person can't have it all
- When a committee member loses portion of their key, new key can be generated and all members get new portions as a result
| ### #7: Lack of governance for an extended period of time. | ||
| -Uncontrolled hard forks by SPOs | ||
| -Risk of no confidence | ||
|
|
There was a problem hiding this comment.
Please explain what the cause of this lack of action is. That would give more context for better suggestions
| -minority controls the outcome | ||
| -can push through any proposal | ||
|
|
||
| Recommendation: |
There was a problem hiding this comment.
Explore quadratic voting or other normalizing strategies to help mitigate minority rule.
|
|
||
| ## Abstract | ||
|
|
||
| As Cardano community led governance comes online, security of the governance mechanism must be addressed in a manner so that all participants are aware of the security weaknesses and how each weakness can be addressed. The guidelines contained in the CIP are relevant to Constittional Committe members, Delegation Representatives, Stake Pool Operators, voters, and Ada holders at large. The guidelines also pertain to how wallet, dApp, and infrastructure developers in general help build situational awareness so that, as development progresses in these areas, consideration in design is given to governance security. |
There was a problem hiding this comment.
| As Cardano community led governance comes online, security of the governance mechanism must be addressed in a manner so that all participants are aware of the security weaknesses and how each weakness can be addressed. The guidelines contained in the CIP are relevant to Constittional Committe members, Delegation Representatives, Stake Pool Operators, voters, and Ada holders at large. The guidelines also pertain to how wallet, dApp, and infrastructure developers in general help build situational awareness so that, as development progresses in these areas, consideration in design is given to governance security. | |
| As Cardano community led governance comes online, security of the governance mechanism must be addressed in a manner so that all participants are aware of the security weaknesses and how each weakness can be addressed. The guidelines contained in this CIP are relevant to Constitutional Committee members, Delegation Representatives (dReps), Stake Pool Operators (SPOs), voters, and Ada holders at large. These guidelines also pertain to how wallet, dApp, and infrastructure developers in general help build situational awareness so that, as development progresses in these areas, consideration in design is given to governance security. |
|
|
||
| ## Motivation | ||
|
|
||
| This CIP intent is to promote awareness of governance security vulnerabilities and possible mitigation techniques in the Cardano ecosystem. The goal is to provide a comprehensive guide describing all known governance security threats and possible mitigiations techniques, but not to address specific software vulnerabilities. The governance security need is present regardless of the final form of CIP-1694 or any other governance document to minimize malicious activities that may occur when a system of voting, elections, and/or on-chain approval of automated actions are present. |
There was a problem hiding this comment.
| This CIP intent is to promote awareness of governance security vulnerabilities and possible mitigation techniques in the Cardano ecosystem. The goal is to provide a comprehensive guide describing all known governance security threats and possible mitigiations techniques, but not to address specific software vulnerabilities. The governance security need is present regardless of the final form of CIP-1694 or any other governance document to minimize malicious activities that may occur when a system of voting, elections, and/or on-chain approval of automated actions are present. | |
| This CIP's intent is to promote awareness of governance security vulnerabilities and possible mitigation techniques in the Cardano ecosystem. The goal is to provide a comprehensive guide that describes all known governance security threats and possible mitigation techniques, but not to address specific software vulnerabilities. The governance security need is present regardless of the final form of CIP-1694 or any other governance document, in order to minimize malicious activities that may occur when a system of voting, elections, and/or on-chain approval of automated actions are present. |
|
|
||
| ## Goals | ||
|
|
||
| Governance on Cardano in this CIP is defined as on-chain decision making that is automatically executed when some threshold of approval by human actors is met. Each threat or vulnerability will be described as a "threat", "description", and the suggested mitigiation technique will be described as a "recommendation" for each type of threat identified in this document. All known threats and mitigations will be made available to public as broadly as possible. The more voters, developers, and governance actors are aware of threats the more likely they are to be identified and mitigated before damage occurs. |
There was a problem hiding this comment.
| Governance on Cardano in this CIP is defined as on-chain decision making that is automatically executed when some threshold of approval by human actors is met. Each threat or vulnerability will be described as a "threat", "description", and the suggested mitigiation technique will be described as a "recommendation" for each type of threat identified in this document. All known threats and mitigations will be made available to public as broadly as possible. The more voters, developers, and governance actors are aware of threats the more likely they are to be identified and mitigated before damage occurs. | |
| in this CIP, governance on Cardano is defined as on-chain decision making that is automatically executed when some threshold of approval by human actors is met. Each threat or vulnerability will be described as a "threat", "description", and the suggested mitigation technique will be described as a "recommendation" for each type of threat identified in this document. All known threats and mitigations will be made available to the public as broadly as possible. The more voters, developers, and governance actors who are aware of a "threat" the more likely it is to be identified and mitigated before damage occurs. |
| Governance on Cardano in this CIP is defined as on-chain decision making that is automatically executed when some threshold of approval by human actors is met. Each threat or vulnerability will be described as a "threat", "description", and the suggested mitigiation technique will be described as a "recommendation" for each type of threat identified in this document. All known threats and mitigations will be made available to public as broadly as possible. The more voters, developers, and governance actors are aware of threats the more likely they are to be identified and mitigated before damage occurs. | ||
|
|
||
|
|
||
| On rare occasion a threat may be identified that requires responsible reporting procedures in order to prevent exposing an active vulnerability to bad actors who may aim to exploit the vulnerability. In the event responsible reporting is required, notify the appropriate group or entity with the responsibility and resources to mitigate such threat in a confidential manner. |
There was a problem hiding this comment.
| On rare occasion a threat may be identified that requires responsible reporting procedures in order to prevent exposing an active vulnerability to bad actors who may aim to exploit the vulnerability. In the event responsible reporting is required, notify the appropriate group or entity with the responsibility and resources to mitigate such threat in a confidential manner. | |
| On rare occasions, a threat may be identified that requires responsible reporting procedures in order to prevent exposing an active vulnerability to bad actors who may aim to exploit the vulnerability. In the event responsible reporting is required, notify the appropriate group or entity with the responsibility and resources to mitigate such threat in a confidential manner. |
| Recommendation: | ||
|
|
||
| ### #13: IGCO - initial governance coin offering | ||
| -offering voters a token of unknown value by a representative to acquire delegators |
There was a problem hiding this comment.
Isn't this a fundamental part of how many SPO's entice delegators to their pools (be they FTs or NFTs)?
So it is needed to somehow differentiate non-explicit IGCOs from actual IGCOs and from simple extra token rewards given to delegators.
| ### #16: Risk of Proposal overload - Risk of DDOS. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- Requiring a minimum amount of ada to be staked by a stake address to create a proposal
- Allowing each stake key to only have one proposal at a time
- A "cool down" period where a proposer cannot submit a new proposal for XX amount of time after the conclusion of their previous proposal for a stake address after their last proposal's vote was concluded
- A "warm up" period that prevents newly delegated ada from proposing for a certain period of time (preventing bad actors from circumnavigating the above)
| Education of correct procedures for DReps | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- The creation of peer-reviewed content to explain a technology in terms anyone can understand, and to independently summarize and verify the pros and cons of a specific technical change. (maybe funded by a treasury to improve impartiality?)
|
|
||
| ### #21: Superstar attack - one “superstar” person that everybody delegates to becomes a dictator with little skin in the game. | ||
| (Example: Elon Musk as a DRep) | ||
|
|
| ### #16: Risk of Proposal overload - Risk of DDOS. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- Require collateral to accompany a proposal (i.e. 50 $Ada or higher)
- Collateral reimbursement once proposal is approved for a voting round or rejected due to constitutional violation
| -overlapping actions and duplicate actions | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- Intentional attempts to submit parameter change proposals that are deemed detrimental to the health of the network should result in a loss of collateral. As mentioned for line 118, collateral should be required to submit proposals.
- overlapping/duplicate actions should be mostly curbed due to collateral requirement. If 1/1 duplicate is successfully proposed, the enforcement of a penalty from collateral as a percentage might be appropriate.
| Education of correct procedures for DReps | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
Curriculum framed from the contents of the constitution and the approved governance CIP (CIP-1694 or otherwise)
| ### #19: Sybil behavior - one person acting as multiple DReps. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- Loss of collateral and expungement of registration. DReps should also be required to submit collateral with their registration. Not dissimilar from a minimum pledge with a stake pool.
|
|
||
| ### #21: Superstar attack - one “superstar” person that everybody delegates to becomes a dictator with little skin in the game. | ||
| (Example: Elon Musk as a DRep) | ||
|
|
There was a problem hiding this comment.
- Collateral exceptions or tiers - A potential process during DRep registration where an approval/finalization process occurs by committee. A tiered collateral model might be appropriate, levied based on certain criteria (i.e. social influence, history of nefarious behavior)
|
|
||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- Proposal should be returned to the DReps with documentation that outlines why a vote of "no confidence" was given, giving the DRep body an opportunity to submit reasons and potential solutions to the proposer(s)
- or a direct revote by the DRep body requiring a strong percentage (3/4?) of votes to the affirmative in order to successfully override the "no confidence" vote.
| ### #25: Ensuring the legitimacy of side chains involved in governance. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- gNodes (Governance Nodes) implemented by process of election
- limit the number of nodes to (100-200)
- disallow DReps and other committee members from operating gNodes
- conflicts of interest should be outlined (i.e. spouses of gNode operators cannot be DReps and vice versa)
- risk of collateral/pledge loss for circumventing outlined accepted practices
- outline requirements for operating a gNode
|
|
||
| ### #1: Unknown software vulnerability affecting governance is discovered. | ||
|
|
||
| Recommendation: The person discovering the vulnerability should document the circumstances and details in which the vulnerability is present and how to reproduce the vulnerability. Then report the vulnerability in a confidential manner using a secure method to the developer team with the resources to correct the vulnerability. |
There was a problem hiding this comment.
A tiered bug bounty rewards program can be employed to recompense those who articulate meaningful corrections required to reverse a potential vulnerability. A treasury may need to be formed to fund this specific activity, releasing those proposed rewards by a committee vote.
|
|
||
| ### #2: Emergency group to support the disaster recovery plan. | ||
| -attacks on persons if known | ||
| -we don’t want attackers know who that group is? |
There was a problem hiding this comment.
"we don’t want attackers to know who that group is?"
| ### #6: DRep keys lost or stolen or DRep keys sold to a bad actor. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
-
Lost/Stolen : DRep must be able to sign with the same wallet/stake key to authenticate for burn/mint of previous key
-
Sold to bad actor : Loss of collateral / Keys destroyed by committee vote
| ### #11: Collusion - the bad version of collaboration to do something illegal or undesirable. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
If this is collusion on the part of any committees members or DReps, it should result in loss of collateral by committee vote. Evidence needs to be presented in a reasonable and articulable way to a body (i.e. Oversight & Accountability Committee), with specific constitutional citations that explains the behavior and/or actions. Voting on such an action must be constitutionally based, not emotionally based.
| ### #15: Persistence - Removal of proposals by attackers. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
I know I continue to suggest collateral. I'm going to do it here, too. If an individual or group of individuals want to remove a proposal, collateral should be required, just as submitting the proposal should. If the removal request is found by committee to be nefarious and/or without merit, a loss of collateral should occur.
Thanks & looking forward to seeing this good material as a CPS 🚀 |
|
see re-submission as CPS: #491 |
This is the initial pull request for a governance security CIP. The CIP is generic to Cardano governance regardless of what type of governance system is adopted. More details are being added at present. More reviewers are being solicited at present.
Rendered in branch