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.

[murchandamus]

Suggested change

* Luke Dashjr ([luke_bipeditor@dashjr.org](mailto:luke_bipeditor@dashjr.org))

[murchandamus]

Inspired by @edilmedeiros’s comment, maybe something along these lines?

Suggested change

	To report a security vulnerability, please send an email to one of the following
	addresses:
	The preferred approach to report a security vulnerability is to directly contact the respective BIP owners and affected projects that implement a BIP. Should attempts to contact the affected parties fail, as a last resort, reports can be sent by email to one or more of the BIP Editors listed below. The contacted BIP Editors will then make their best effort to triage the report and get in touch with the respective parties.