I know and I completely disagree with that decision.
HPKP has a place. Checking CA logs (via Expect-CT header) is bullshit because when the stakes are high enough some CA can get hacked or some low level sysadmin can verify domain control somehow and register a cert and some actor can MITM connections without anyone noticing for months.
With HPKP the fucking page doesn't load. Period. You need to either root the server or use a PDA to stop HTTPS in the first place, but then the browser bar isn't green. If the costs of getting MITMed are high it is better to risk lockout than it is to risk silent data loss.
At the very, very least I should be able to pin which CAs I trust so the threat vector doesn't include every CA in the world.
The Expect-CT header is good enough for most people, but HPKP should be supported if needed.
This always seemed backwards to me. If the worry is that certs are being misissued, why on earth are we assuming that such CAs are following the rulebook?
No, the browser should check the CAA record and refuse to trust certs issued by the wrong CA.
This would only make sense under the assumption that the DNS response can be trusted. For the vast majority of domains and resolvers, that would not be the case. (I'm skipping the discussion of whether you'd want to trust DNSSEC at all.)
The idea you're describing has been standardized as DANE, which has failed to gain any adoption. It would not make sense for CAA to try to do the same thing. Instead, it set out to provide a defense-in-depth mechanism for certain CA vulnerabilities that fall short of a full compromise.
I hate this, too, and would love to be able to use HPKP in the future, too.
But I’ve long accepted that Google will simply drop functionality without reason even when people still depend on it, just because they can, and that they’re deaf to all complaints.
