Add SECURITY.md

[jonatack]

This information is already in BIPs 2 and 3, but ISTM that an explicit SECURITY file would conform to current best practice.

I did not include a section about gpg keys to communicate sensitive information; if wanted, it could be added here or later.

[murchandamus]

I’m not sure I understand the motivation here. Since we don’t ship a software project, what responsible disclosures could we possibly get?

[jonatack]

No strong opinion but idea is, what if an issue is found in a specification (or its example implementation) here that could lead to a potential vulnerability/exploit in an implementation.

[ajtowns]

I would think that for a deployed standard, contacting the implementations directly initially would be wise, then adding a "this spec should not be implemented" warning until full disclosure is reasonable. I don't think adding the BIP editors as middlemen for contacting implementations is likely to help anyone out -- half the time it seems like BIP editors have a hard enough job getting into contact with BIP authors as it is even when there's not some looming disaster...

[jonatack]

for a deployed standard, contacting the implementations directly initially would be wise

Yes. It might be worthwhile to state this here.

then adding a "this spec should not be implemented" warning until full disclosure is reasonable

The red team or the implementation would need to contact us privately, so having the contact emails easily findable like here seems useful.

[ajtowns]

then adding a "this spec should not be implemented" warning until full disclosure is reasonable

The red team or the implementation would need to contact us privately, so having the contact emails easily findable like here seems useful.

If your goal is to publicly update a spec to recommend everyone stop using it, then I don't think there's anything that needs to be done in private. Probably having one of the (co-)authors open a PR with the extra text and merging it as soon as it's verified it's not an impersonator is the ideal outcome. If the authors aren't in the loop, I think marking a BIP as having security issues wouldn't actually comply with BIP 3 processes anyway?

[edilmedeiros]

I believe IETF has a reasonable advisor and process.

tldr:

While the preferred approach to reporting IETF protocol vulnerabilities is to contact the person or group responsible for the document, as a last resort, reports can always be sent by email to protocol-vulnerability@ietf.org. The IETF Security Area Directors will make their best effort to triage the report.

I believe having a single email for security reports is considered a best practice instead of many individual emails. Never understood it completely because that single email distributor can be compromised.

[jonatack]

Updated with your feedback @ajtowns @edilmedeiros @murchandamus (thanks!)

@edilmedeiros I wanted to add you as co-author but I don't have your git-related email yet.

[murchandamus]

I think it’s jose.edil@gmail.com per a recent commit of his. Maybe you can put it in already and @edilmedeiros can confirm.

(Did you know that you can look at a commit directly by adding .patch to the URL of a commit?)

[jonatack]

Updated, thanks! TIL.

[murchandamus]

Maybe this should include our GPG keys, so emails can be encrypted?

[edilmedeiros]

I think it’s jose.edil@gmail.com per a recent commit of his.

Yes, this email. Thanks.