Update security.md with all PGP fingerprints

ariard commented at 9:31 pm on February 1, 2024: member

As a bitcoin sec researcher, appreciated if PGP fingerprints of all receiving endpoints of security@bitcoincore.org can be public. Thanks.

achow101 commented at 9:41 pm on February 1, 2024: member

The full recipients list of security@bitcoincore.org is intentionally kept private in order to reduce the risk of targeted attacks against those who receive those emails. Only the people who are willing to take that risk have their fingerprints published.

1440000bytes commented at 10:03 pm on February 1, 2024: none

In case someone is not comfortable notifying all the unknown members of security@bitcoincore.org email list, an alternative could be to directly email one or more developers mentioned here: https://github.com/bitcoin/bitcoin/security

epiccurious commented at 11:43 pm on February 1, 2024: none

+1 to @1440000bytes, they can contact the listed people directly instead of security@.

maflcko added the label Questions and Help on Feb 2, 2024

willcl-ark commented at 8:07 pm on February 4, 2024: contributor

@ariard does being able to contact the persons who have chosen to be listed resolve this issue for you?

bitcoin deleted a comment on Feb 4, 2024

ariard commented at 9:59 pm on February 4, 2024: member

The full recipients list of security@bitcoincore.org is intentionally kept private in order to reduce the risk of targeted attacks against those who receive those emails. Only the people who are willing to take that risk have their fingerprints published.

As a sec researcher, you’re exposing your own skin too by handling sensitive information to unknown members of a list. Encrypting communications and knowing who are the endpoints to guarantee infosec ethics are best practices in my eyes.

achow101 commented at 10:14 pm on February 4, 2024: member

Encrypting communications and knowing who are the endpoints to guarantee infosec ethics are best practices in my eyes.

Then encrypt your emails to any of the published keys and no one else on the list will be able to read your emails.

ariard commented at 10:21 pm on February 4, 2024: member

Then encrypt your emails to any of the published keys and no one else on the list will be able to read your emails.

Thanks if the 3 published PGP fingerprints can add an authoritative dedicated mail. No wish to go through email alias. You don’t answer my second q on infosec ethics, and transparency if re-sharing of sensitive info with unknown members.

achow101 commented at 10:30 pm on February 4, 2024: member

Thanks if the 3 published PGP fingerprints can add an authoritative dedicated mail.

PGP keys contain emails, signed by the key itself. That is itself authoritative for each person. If you really want to, email those people directly, encrypted to their keys.

You don’t answer my second q on infosec ethics, and transparency if re-sharing of sensitive info with unknown members.

You didn’t ask one, you made a statement, which I think is sufficiently addressed by encrypting directly to the people who you want to share the information with.

achow101 closed this on Feb 4, 2024

ariard commented at 3:26 am on February 5, 2024: member

@achow101

Thanks to not use your GH admin rights to close issue before someone is satisfied with your answer.

This is a qualified lack of professionalism for an open-source maintainer as such as Bitcoin, which is engaging your own reputation.

achow101 reopened this on Feb 5, 2024

ariard commented at 3:29 am on February 5, 2024: member

FYI - I raised the subject of securing line of sensitive communications at one of the last in-person coredev.

achow101 commented at 3:30 am on February 5, 2024: member

I considered the question posed in the OP to be answered and that there was nothing further to do here.

Since you disagree, what exactly is it that you are asking? I’m having a hard time parsing from your responses what further questions you actually have other than whether the full list can be published.

ariard commented at 1:47 am on February 8, 2024: member

As usual with any question posed in the OP, wait or ask first if the opener is satisfied (modulo basic trolling / gpt-spam ofc).

I’m asking a) for the full sec-list to be public b) for each member to have a PGP fingerprint available and c) a dedicated sec mail address for each endpoint instead or in redundancy of using an alias. I understand and I know the risk of targeted attacks on members, I think it has to be weighted with better accountability.

PGP every communications of sensitive info hardens against eventual interceptions by adversaries and beyond it allows to apply ethical monitoring among participants to a given vulnerabilities responsibility group, e.g see linux kernel memorandum of understanding (https://www.kernel.org/doc/html/v6.8-rc1/process/embargoed-hardware-issues.html#memorandum-of-understanding). I’m not giving a wildcard on core sect list members on this concern.

If full publicity is an overwhelming personal risk model for some sec list members, they can think more about it and take time to resign, I can understand. Of course, handling sensitive bitcoin info can expose you to risks, let’s be realistic about it. I think it’s good to have this discussion about it over the coming weeks or months.

maflcko commented at 9:31 am on February 8, 2024: member

The page you link to says:

The hardware security team identifies the developers (domain experts) who will form the initial response team for a particular issue. The initial response team can bring in further developers (domain experts) to address the issue in the best technical way.

While I am not on the security list and never was, nor have knowledge of its internals, it seems plausible to me that the recipients may pull in further developers or domain experts that are not on the list, if there is need to. Again, I don’t know if there was ever need to, but it seems plausible that in the future, at some point there may be. I don’t think it is practical (or even possible) to list the keys of all further developers or domain experts, ignoring the fact that such a list would be subjective and not well defined at any point in time.

In any case, you are always free to pick the list of recipients yourself. PGP keys usually have a mail in their metadata, so you can simply pick the PGP keys and the corresponding mail addresses. You are also free to limit the initial disclosure to a smaller group of recipients and then widen it, as you see fit, as the discussion progresses. Finally, you can communicate how you wish your disclosure to be handled. For example, you can provide a list of recommended domain experts yourself (e.g. the authors of a BIP), if you think that it would be useful.

glozow commented at 12:33 pm on February 10, 2024: member

I agree this can be closed as not planned. You can encrypt your communications to a specific key. The linked page seems to have the same practice we do. There seems to be an accusation that the security list is untrustworthy, leading to demands that we do things that are nonstandard, put people at risk for no reason, and ultimately unhelpful to handling security issues.

mzumsande commented at 8:02 pm on February 10, 2024: contributor

Also, the linked page refers only to the special case of embargoed hardware issues. For the topic of software security bugs in the linux kernel (which seems like a better comparison), the page https://www.kernel.org/doc/html/v6.8-rc1/process/security-bugs.html applies, which points to a “private list of security officers” where no member is explicitly named.

epiccurious commented at 3:48 am on February 11, 2024: none

points to a “private list of security officers” where no member is explicitly named

In light of this, @ariard are you comfortable closing the issue? If not, what specific objection?

ariard commented at 8:48 pm on February 11, 2024: member

For everyone knowledge, Linux kernel has a separation between software security bugs and hardware ones for good historical reasons. Few years ago, in the handling of Meltdown / Spectre (the 1st gen of transient execution CPU vulnerabilities), early leaks of the issues did happen. Since then, the kernel and OS folks have put in place clearer security handling policy to coordinate vulnerability response, including expelling members from future security incidents who are not respecting embargo deadlines or information contingency policy.

See the following except in the Linux embargoed hardware sec documentation:

“The hardware security team will provide the disclosing party a list of developers (domain experts) who should be informed initially about the issue after confirming with the developers that they will adhere to this Memorandum of Understanding and the documented process.”

On the untrustworthiness of the security list - Sadly, yes this is something we should talk about either in public or private (don’t trust, verify). As a security researcher and someone who has been working on vulnerability mitigation and disclosure coordination process, in the past I’ve been asked by LN maintainers to segregate some security information from the usual set of Core people handling issues. There is no need to distribute the information to a wider set of people than strictly necessary (see need to know policy). I do think Core having a clear policy at the image of the Linux kernel ones for cross-layer security handling would be very helpful. Fact is for now there is just no standard at all.

For anyone (either past or current core maintainer) asking to blindly “trust” the sec list member, let’s all remember the Gavin Andresen story, where its own maintenance rights has to be revoked from a day to another. I think this is a reasonable lesson to follow the principle of least privilege here.

For everyone information, I do have an old version of the security list members (no I didn’t buy it on the black market from an intel agency - I just got it during one of my past interaction with the list as someone screw up the server configuration…). So on my side, it’s not really knowing who is on it, it’s more about putting in place default-encrypted communications and “need to know” policy to make cross-layer security issues handling more straightforward.

So I think it would be reasonable to have the SECURITY.md modified where a security researcher as the initial disclosing party can ask the list of developers (domain experts) who will be informed initially about the issue and have them committed in some written record to a memorandum of understanding and documented process.

If anyone on the list or any core maintainer has the sentiment I’m taking them by “surprise” I can understand them. Those people are free to reach out me in private if they have questions, they have my contact. Yet they should be ready to receive critical security information at anytime, so saying you’re not “comfortable” is an avowal of weakness in my eyes and they shouldn’t work on sec issues of a backbone infra playing a part in a $1T project. It’s kinda the “navy seals” or “legion etrangere” of open-source software here in my opinion.

To be fair, I’ve pushed this conversation at CoreDev in Dublin, yet actually half-of the folks of the sec list where not present and 90% of the audience listening to my talk don’t have practical experience with sec issues handling so it made it a non-starter. Talking about it in public, sounds the only way to push forward the conversation. Refusing the conversation puts me in the position where I would have to improvise a mitigation and coordination process next time I found a substantial cross-layer security issue (it did happen every each 6 / 8 months over the last 4 years) or even found something affecting the stability of the base-layer (apologies I’m just to talented in matters of breaking things).

So unless someone has strong objections, I can open a PR to submit a draft on the example of the Linux one.

achow101 commented at 9:58 pm on February 11, 2024: member

I still don’t understand what specific concern that you have. I don’t understand what specific problem you are trying to solve by making the list of recipients public. Are you concerned about particular individuals on the list or is this a general concern of vulnerabilities leaking because there are too many people? Either way, it seems like the solution is to encrypt your communications to specific people, and you are free to ask them to inform you who will be involved in fixing the problem.

ariard commented at 11:52 pm on February 11, 2024: member

Actually both. Concerned about particular individuals on the core sec list who have lost my trust (i.e some chaincode folks - their intentions are still troubling to me - no private answer from their side to clarify) and vulnerabilities leaking because there are too many people.

One more concern, indelicate individuals using vulnerabilities knowledge to get benefit if any disclosure induce market-moving activities, or even quick change in network mempools congestion. I did voice those issues in private on one of my last security response endeavor.

I’m satisfied with your answer that I’m free to ask specific people disclosed to who will be involved in fixing the problem, and make it clear if for mitigation and coordination purposes I refuse to work with a subset of people as the original disclosing party based on bad antecedents with this eventual subset. My preference would be to commit in text like linux is doing, For today I’m satisfied with your answer and I’ll take you on your words in the future.

Long-term we should still PGP and OTS every sec communication, especially as vulnerability response group starts to be bigger with different codebases affected…For now I’ll satisfy with that, and it’s okay to get stuff done.

ariard closed this on Feb 11, 2024

glozow commented at 10:22 am on February 12, 2024: member

in the past I’ve been asked by LN maintainers to segregate some security information from the usual set of Core people handling issues. There is no need to distribute the information to a wider set of people than strictly necessary (see need to know policy).

One potential solution to this problem is to stop CCing unrelated people on your disclosure emails.

ariard commented at 6:04 pm on February 15, 2024: member

One potential solution to this problem is to stop CCing unrelated people on your disclosure emails.

I’m always adding people on embargoed communications for strong technical or operational reasons (e.g timezones) and based on their professional experiences. Embargoed communications not be confused with disclosure emails. In the future, I”ll apply “no-chaincode / no-spiral” as I cannot trust their group incentives for now and they show no sign to clarify their pattern of behaviors. Frankly, I think very few people in the bitcoin space have my level of experience, know-how and scope of concerns in matters of handling sensible security issues (who else ? Greg Maxwell ? Peter Todd ?). Thanks.

edited - as I made a typo at first.

Update security.md with all PGP fingerprints #29366