Re: CA's TLS Certificate Bundle in base = BAD

On Dec 3, 2022, at 5:26 PM, grarpamp <grarpamp@gmail.com> wrote:
> 
> Again, FreeBSD should not be including the bundle in base, if users
> choose to, they can get it from ports or packages or wherever else.
> Including such bundles exposes users worldwide to massive risks.
> You need to do more gpg attestation, pubkey pinning [1], tofu, and
> cert management starting from empty file... and quit trusting bundles of
> hundreds of random CA's, all of which are entities who have zero duty
> or care to the user, and often exist/corrupt/break to present evil [2] ...
> 
> [1]
> https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
> https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
> 
> FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option,
> thus they're incapable of securely fetching packages, iso's, etc from
> servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys
> for users to get, verify, and pin out of band. Even pubkeys were swapped out
> on FreeBSD servers without announcing for users if any exploit or loss occurred
> there or for some other reason. That's all bad news :( But can be fixed :)

Key pinning is a bad idea that 100% will cause outages.

As a thought experiment, let's suppose I (as the Security Officer) use the system you propose and require users to pin specific keys on our publicly available servers. Now let's further suppose that the project is compromised such that we believe those certificates might be in the hands of the attacker, but we aren't sure. I'm now stuck between a rock and hard place. Should I rotate the pinned certificate? In your proposed system, rotating that pinned certificate will cause massive downstream failures for all users. Since we aren't sure, maybe I'll leave the existing certificate in place, because I don't want to cause those outages since I'm not sure it's a problem.

In the publicly trusted CA system, I can easily rotate the certificate even if I don't believe it was compromised. It incentivizes better behavior. Also, please don't lecture me on the problems with the publicly trusted CA system: I'm very familiar with them. That said, it's the system we have and I have no interest in trying to tilt at that particular windmill.

In any event, nothing is preventing you from doing this on your own as the system ships with the tools to do so. Recognize the project has a need for cryptographic agility and ability to change certificates whenever we need to. Running our own root CA infrastructure necessary to provide a similar level of assurance to a professionally run CA is non-trivial and I don't believe we as a project are in a position (or interested) in taking on such a burden.

Gordon