Improve RFC, incorporating all suggestions made by reviewers.

Co-Authored-By: Mike Bursell <[email protected]>
Co-authored-by: Lily Sturmann <[email protected]>
Co-authored-by: blazebissar <[email protected]>

concepts/Vulnerability_disclosure_and_embargo_policy/00004-Vulnerability_disclosure_and_embargo_policy.md

@@ -9,7 +9,7 @@
 
 ## Summary
 
-Describe the security vulnerability disclosure process, including embargoes.
+A description of the security vulnerability disclosure process, including embargoes.
 
 ## Motivation
 
@@ -19,10 +19,10 @@ also be able to have an idea of how we use security embargoes.
 
 In other words:
 - We want:
-  - to encourage reporting of security issues (ie: “attack us!”)
+  - to encourage reporting of security issues (ie: “Please do attack us!”)
   - to make it easy to report security issues
   - to maintain and extend our policy of safe defaults / discouraging people
-  from using bad security practices
+  from adopting bad security practices
   - to recognise and show appreciation for the time spent researching and
   reporting
   - to make it possible for people who may be at risk to report issues
@@ -41,12 +41,12 @@ In other words:
 
 ## Tutorial
 
-This RFC aims to provide a set of documents (wiki pages) that describe the 
-Enarx vulnerability disclosure policy and the list of security advisories and
- fixes.
+This RFC aims to provide a set of documents (ex. wiki pages) that describe the 
+Enarx vulnerability disclosure policy - including the use of embargos - and
+the list of security advisories and fixes.
 
 The two pages are "Vulnerability Reporting and Embargo Policy" and "Enarx 
-Security Advisories"
+Security Advisories."
 
 --- 
 ### Vulnerability Reporting and Embargo Policy
@@ -61,65 +61,91 @@ Vulnerabilities may be discovered in:
 3. Enarx documentation
 4. 3rd party hardware or firmware
 
-All security bugs in Enarx should be reported by email to [email protected]. 
-This list is delivered to a small security team. Your email will be 
-acknowledged within 48 hours, and you’ll receive a more detailed response to 
-your email within 96 hours indicating the next steps in handling your report.
- If you wish, you may encrypt your report using our public key. This key is 
-also on keys.openpgp.org and reproduced below.
-
-Be sure to use a descriptive subject line to avoid having your report be 
-missed (as with any publicly listed addresses, it is expected this one will 
-get a lot of spam). After the initial reply to your report, the security team
- will endeavor to keep you informed of the progress being made towards a fix 
-and full announcement. As recommended by 
+All security bugs in Enarx should be reported to the security team. 
+To do so, please reach out either by email at [email protected] or on our
+[chat](https://chat.enarx.dev) stating you'd like to report a security
+issue, but **without divulging details**.
+
+We treat both email and chat as a public channels, so simply saying that
+you’re trying to get a hold of someone from the security team is fine.
+
+From then, we will establish a more secure area where the issue can be
+discussed, in the form of a 
+[Github Security Advisory](https://help.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories).
+
+You will be invited to join this private area to discuss specifics. Doing so 
+allows us to start with a high level of confidentiality and relax it if the 
+issue is less critical, moving to work on the fix in the open.
+
+This method provides several other advantages:
+1. Avoids email, which is unfortunately very difficult to use securely
+2. Enables private collaboration to fix the vulnerability in 
+a temporary private fork
+3. Facilitates drafting a security advisory and using the draft to 
+privately discuss the impact of the vulnerability on the project
+4. Simplifies publishing the security advisory and alerting the 
+community of the vulnerability
+
+Your initial contact will be acknowledged within 48 hours, and you’ll receive 
+a more detailed response within 96 hours indicating the next steps in handling 
+your report.
+
+After the initial reply to your report, the security team  will endeavor to 
+keep you informed of the progress being made towards a fix and full 
+announcement. As recommended by 
 [RFPolicy](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt),
  these updates will be sent at least every five working days.
 
-If you have not received a reply to your email within 72 hours, or have not 
-heard from the security team for the past five days, there are a few steps you
- can take (in order):
-- Contact the current security coordinator (Nathaniel McCallum (public key)) directly.
-- Contact the back-up contact (Mike Bursell (public key)) directly.
-- Come chat to us on the [chat](https://gitter.im/enarx/community).
+If you have not received a reply to your initial contact within 96 hours, or
+have not heard from the security team for the past five days, there are a few
+steps you can take (in suggested order):
+- Contact the current security coordinator (Nathaniel McCallum, aka
+[npmccallum](https://github.com/npmccallum)) directly
+- Contact the back-up contact (Mike Bursell, aka 
+[MikeCamel](https://github.com/mikecamel)) directly  
+  In both these cases, you can reach out
+  - by email
+  - by chat
+- Contact the team as a whole on the [chat](https://chat.enarx.dev).
 
-Please note that the chat is a public area. When escalating in these venues,
-please do not discuss your issue. 
-Simply say that you’re trying to get a hold of someone from the security team.
+As a reminder, **when escalating in these venues, please do not discuss your
+issue.** 
 
-Should you need to transfer files to us in a private manner, please use 
-[Magic Wormhole](https://magic-wormhole.readthedocs.io/en/latest/) or make 
-them available over https.
+Lastly, should you need to transfer files to us in a private manner, please 
+use [Magic Wormhole](https://magic-wormhole.readthedocs.io/en/latest/) or 
+make them available over https.
 
 
 #### Disclosure policy
 The Enarx project has a 5 step disclosure process.
-1. The security report is received and is assigned a primary handler. 
+1. Contact is established, a private channel created, and the security report 
+is received and is assigned a primary handler. 
   This person will coordinate the fix and release process.
 2. The problem is confirmed and a list of all affected versions is determined.
+  2.1 If an embargo is needed (see below), details of the embargo are decided.
 3. Code is audited to find any potential similar problems.
 4. Fixes are prepared for all releases which are still under maintenance. 
-  These fixes are not committed to the public repository but rather held 
-  locally pending the announcement.
-5. On the embargo date, an announcement is sent to Enarx public channels 
-  (chat, website). The changes are pushed to the public repository and new 
-  builds are deployed.
+  4.1 In case of embargo, these fixes are not committed to the public 
+  repository but rather held in a private fork pending the announcement.
+5. The changes are pushed to the public repository and new builds are deployed.
+  An announcement is sent to Enarx public channels (chat, website), once
+  these are available.
 
 This process can take some time, especially when coordination is required 
-with maintainers of other projects. Every effort will be made to handle the 
-bug in as timely a manner as possible, however it is important that we follow
- the release process above to ensure that the disclosure is handled in a 
-consistent manner.
+with maintainers of other projects or, for instance, with hardware vendors. 
+Every effort will be made to handle the bug in as timely a manner as possible, 
+however it is important that we follow the release process above to ensure 
+that the disclosure is handled in a consistent manner.
 
 Enarx does not provide financial rewards for security disclosures, but the 
-team is open working with reporters of issues on publishing and attribution 
-of vulnerabilities and fixes.  We welcome reports of issues to the project, 
+team is open to working with reporters of issues on publishing and attribution 
+of vulnerabilities and fixes. We welcome reports of issues to the project, 
 and want to ensure that the community is aware of and celebrates security 
 improvements.
 
 #### Embargoes
 While the Enarx project aims to follow the highest standards of transparency 
-and openness (cf. [Enarx Principles](https://github.com/enarx/enarx.github.io/wiki/Design-principles)), 
+and openness (cf. [Enarx Principles](https://github.com/enarx/enarx/wiki/Design-principles)), 
 handling some security issues may pose such an immediate threat to various 
 stakeholders and require coordination between various actors that it cannot 
 be made immediately public.
@@ -134,8 +160,9 @@ An embargo can be called for in various cases:
 - when proper analysis of the issue and its ramifications demands time.
 
 If we determine that an issue you report requires an embargo, we will discuss 
-this with you and try to find a reasonable expiry date (aka “unembargo date”), 
-as well as who should be included in the list of need-to-know people.
+this with you and try to find a reasonable expiry date (aka “embargo 
+completion date”), as well as who should be included in the list of 
+need-to-know people.
 
 In any case, embargoes are a process that should be used sparingly, as they 
 are painful and time-consuming.
@@ -169,38 +196,37 @@ N/A
 
 Much of this RFC is inspired by the [Rust Security Policy](https://www.rust-lang.org/policies/security),
 as well as [RFPolicy 2.0](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt), 
-which it refers to.
+to which it refers.
 
 ## Drawbacks
 
-- The process as currently described makes use of email and OpenPGP. PGP 
-  email is notoriously hard to get right, even more so over time.
+- This process opts for a "secret by default" approach, as any security issue 
+reported will automatically be in a private area. This may seem at odds with 
+our goal of transparency. We may need a clear set of criteria according to 
+which we make a security report public rather than go for / maintain an embargo.
 
 ## Rationale and alternatives
 
 - The most basic alternative is not to have a policy and to simply wait for
 people to disclose their findings. This does nothing to provide guarantees 
 to researchers and users that their work and time will be respected and to 
-encourage further disclosures.
+encourage further disclosures.  We do not believe that such an approach would be consistent with the transparency and openness goals of the Enarx project.
+- Offer full reporting of security vulnerabilities by email, as many other 
+projects do, and which is what many researchers will be used to.  
+However, encrypted email is not a good solution. The only usable standard for 
+encrypted email is OpenPGP, which suffers from very poor usability, offers no 
+Perfect Forward Secrecy (PFS) and imposes complex and painful key management 
+on the recipients as well as the senders. Cf. [this analysis](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html), 
+for more insights.
 
 ## Prior art
 
 Rust process mentioned above.
 
 ## Unresolved questions
-As mentioned, encrypted email is not a good solution. It’s really hard to get 
-PGP encrypted email right, it offers no Perfect Forward Secrecy (PFS) and key 
-management is horrible (cf. [this analysis](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html), 
-for instance). However, in the case of just offering a way for people outside 
-Enarx to send sensitive information with _some_ security, it may be 
-acceptable. 
-Key management is still hard: how many copies of the private key? where do 
-they live? how do we revocate if maintainers leave project? etc.
-
-In light of this:
-- Can we *not* offer email as a way communication channel while remaining 
-universal enough to allow everyone to report security issues in Enarx?
-- Should we treat email as a public channel, similar to our chat?
+Can this process be seen as contradictory with our intention to minimise the 
+use of embargo, and can we make clearer that we don't intend to make every 
+security report secret?
 
 ## Implementations
 
@@ -213,9 +239,13 @@ disclosure.
 
 Some ideas are:
 - Github: work with Github on security issues reporting (WIP)
-- A Private Github repo
+- Use RocketChat, our current [chat platform](https://chat.enarx.dev)  RocketChat's capacity for with end-to-end 
+  encryptted conversations.
 - [Keybase](https://keybase.io/encrypt) messaging
 - [Signal](https://signal.org): raises question which account (ie: phone number)
+- A OMEMO or OTR enabled Jabber / XMPP account (OMEMO offering the advantage 
+  of allowing to establish a secure channel without both participants being 
+  online)
 - [Secure Drop](https://securedrop.org/) (initially designed for as a way to 
   share and accept documents securely for news organisations, likely overkill)
 - A simpler drop box over HTTPS