Create a Security Policy

[joycebrum]

Public Suffix List (PSL) Pull Request (PR) Template

Each PSL PR needs to have a description, rationale, indication of DNS validation and syntax checking, as well as a number of acknowledgements from the submitter. This template must be included with each PR, and the submitting party MUST provide responses to all of the elements in order to be considered.

Checklist of required steps

• Description of Organization: N/A
• Robust Reason for PSL Inclusion: N/A
• DNS verification via dig: N/A
• Run Syntax Checker (make test): N/A
• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section : N/A

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• This request was not submitted with the objective of working around other third-party limits

• The Guidelines were carefully read and understood, and this request conforms

• The submission follows the guidelines on formatting and sorting

---

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

---

Description

It is important to have a Security Policy in order to show users how to report their findings safely. I've opted for using the report through GitHub Security Advisories (mentioned in the Issue #1855 ) but it is also possible to ask for them to be reported through a given email. If that's what you prefer, let me know or feel free to edit the policy directly.

Closes #1855

[dnsguru]

on line 11, can you add a sentence:

Reports are limited to repo matters. Any vulnerability reports related to the addition or removal of PSL entries in the .dat file shall be rejected and referred to filing pull requests that should make mention the alleged urgency.

[dnsguru]

I appreciate you're doing this, as it is one of dozens of "debts" that have gone un-resourced due to there being scant resourcing here on this project.

[joycebrum]

Done!

[mozfreddyb]

I can take this review further. I want to suggest two changes:

I believe the sentence Reports are limited to repo matters. Any vulnerability reports related to the addition or removal of PSL entries in the .dat file shall be rejected and referred to filing pull requests that should make mention the alleged urgency. should come a lot earlier. Burying the lede will only cause annoying busy work for everyone involved.

Secondly, if @dnsguru agrees I would like to add [email protected] as a notification email address to inform after filing a new advisory here. This will reach people who are watching diligently at all times, of which 2 already have repository access. I think this would be beneficial - the notification characteristics would ensure that all important information remains in this repository and it will help expedite the handling of important changes when needed.

[joycebrum]

Hi, I've followed the suggestion to move the sentence for the beginning of the section. Let me know if it is better now.

Besides, I've looked for the option for configuring the security advisories notifications to go to a different email, but I wasn't able to find such configuration. This is what I've found: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository#configuring-notifications-for-private-vulnerability-reporting

Although I agreed this would be an interesting feature to have.

I could, instead, add a sentence asking the reporters to also notify for the given email linking to the opened report.

[dnsguru]

I like Frederik's suggestion, perhaps with a mild "plus-up" to deal with the reality of the situation - the alleged urgency is something that even if stated, we absolutely have zero control over what downstream will do, and should likely be very explicit about what expectations should be about this with the reporting party. My concern with all this "Security Policy" stuff comes from situations where a reporting party seeking to address a namespace issue is likely to file a report and make assumptions that they have sent it to the right place or that it would have ANY resolution if it were related to changes in the PSL. We are rapidly entering into a situation where perpetrators will be either requesting entries or abusing the majority of existing ones due to increasing pressures on the registry/registrar space in combination with regulatory changes. If a party reports an issue with a namespace that has been added, and needs them removed for cause, they need a means to prove their case and also a lot of patience while the removal would propogate. AND these are time-investment for each request, in order to avoid friendly-fire situations. All best to avoid misunderstandings with respect to "Security Policy" proactively.

…

On Mon, Nov 6, 2023 at 12:50 AM Frederik Braun ***@***.***> wrote: I can take this review further. I want to suggest two changes: I believe the sentence Reports are limited to repo matters. Any vulnerability reports related to the addition or removal of PSL entries in the .dat file shall be rejected and referred to filing pull requests that should make mention the alleged urgency. should come a lot earlier. Burying the lede will only cause annoying busy work for everyone involved. Secondly, if @dnsguru <https://github.com/dnsguru> agrees I would like to add ***@***.*** as a notification email address to inform *after* filing a new advisory here. This will reach people who are watching diligently at all times, of which 2 already have repository access. I think this would be beneficial - the notification characteristics would ensure that all important information remains in this repository and it will help expedite the handling of important changes when needed. — Reply to this email directly, view it on GitHub <#1856 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJIAZ7N3DPUOATWWTODYDCQHDAVCNFSM6AAAAAA4Y4PE4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJUGMZTMNZVHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mozfreddyb]

This looks better, thanks for taking my feedback.

I think to @dnsguru's point, it sounds like a great idea to preface the Reporting section with a section on What we consider to be a vulnerability that we are interested in at all (and what we are not). I think this will help set expectations and reduce false positives.

[mozfreddyb]

Please disclose it at security advisory and send an email with the link to the newly filed issue to [email protected] to expedite the review on our end.

[joycebrum]

Done

[simon-friedberger]

This looks good to me now. I would suggest merging.

[mozfreddyb]

Agreed, this is good to go :)