Primary eng (and PM) emails
palmer@chromium.org, rsleevi@chromium.org, estark@chromium.org, agl@chromium.org
Summary
Deprecate support for public key pinning (PKP) in Chrome, and then remove it entirely.
This will first remove support for HTTP-based PKP (“dynamic pins”), in which the user-agent learns of pin-sets for hosts by HTTP headers. We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018.
Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)
Motivation
PKP offers a way to defend against certificate misissuance, by providing a Web-exposed mechanism (HPKP) for sites to limit the set of certificate authorities (CAs) that can issue for their domain. However, this exposes as part of the Open Web Platform considerations that are external to it: specifically, the choice and selection of CAs is a product-level security decision made by browsers or by OS vendors, and the choice and use of sub-CAs, cross-signing, and other aspects of the PKI hierarchy are made independently by CAs.
As a consequence, site operators face difficulties selecting a reliable set of keys to pin to, and adoption of PKP has remained low. When site operators’ expectations don’t match the reality of trust anchors on real world client machines, users suffer. Unexpected or spurious pinning errors can result in error fatigue rather than user safety.
Concretely:
It is hard to build a pin-set that is guaranteed to work, due to the variance in both user-agent trust stores and CA operations.
There is a risk of rendering a site unusable.
There is a risk of hostile pinning, should an attacker obtain a misissued certificate. While there are no confirmed or rumored cases of this having happened, the risk is present even for sites that don’t use PKP.
Interoperability And Compatibility Risk
There is no compatibility risk; no web site will stop working as a result of the removal of static or dynamic PKP.
Edge: Currently does not support key pinning.
Firefox: No official signals yet.
Safari: Currently does not support key pinning.
Opera: If Opera wishes to continue to support pinning, they will need to carry a patch that reverts our diff(s).
Alternative implementation suggestion for web developers
To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function. Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs. Site operators can generally deploy Expect-CT on a domain without needing to take any additional steps when obtaining certificates for the domain. Even if the CT log ecosystem substantially changes during the validity period of the certificate, site operators can provide updated SCTs in the form of OCSP responses (if their CA supports it) or via a TLS extension (if they wish for greater control). The combination of these mitigations substantially reduces the risk of DoS (either accidental or hostile) via Expect-CT deployment. By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning.
Usage information from UseCounter
Scott Helme found in August 2016 that very few of the Alex Top 1 Million sites were using HPKP (375) or the Report-Only (RO) variant (76): https://scotthelme.co.uk/alexa-top-1-million-crawl-aug-2016/. My own scans (using slightly different/additional corpora) earlier in 2016 showed even lower numbers.
The UMA histogram Net.PublicKeyPinSuccess records a high number of successes, but it includes popular domains for which Chrome has static key pins: likely Google sites.
The UMA histogram Net.PublicKeyPinReportSendingFailure2, which is probably a much better indication of dynamic PKP adoption than Net.PublicKeyPinSuccess, shows extremely low numbers of success and failure, indicating that very few sites are using it, and/or that only very low-traffic sites are using it.
If necessary, we can add UMA histograms to find the ratio of HTTP responses with and without HPKP(-RO) headers.
OWP launch tracking bug
The Chromium tracking bug is crbug.com/779166.
Entry on the feature dashboard
I’m not sure if we need this. If we do, I’ll add one.
Requesting approval to remove too?
Yes.