Thanks for posting about this. It’s something I’ve been thinking about a bunch, especially in relation to Symantec’s recent emergency issuance to a customer that had hardcoded a specific intermediate, which became obsolete.
I’d like to take the advice in HPKP best practices if you choose to implement and make it an official documentation page, but with similarly many caveats and warnings. I think if we did so, I would want to say “Let’s Encrypt does not officially support HPKP, but here’s how to do it in the safest way if you choose to.” As folks have pointed out here, safe HPKP deployment involves two important choices that require thought and care: Which two non-LE CAs are you going to pin, and how are you going to generate and safeguard your backup key? I think neither of those is amenable to copy-and-paste coding, and providing off-the-shelf hashes may encourage people to deploy HPKP unsafely and brick their site.
Peter, to your objective of “removing all non-cryptographic attack surfaces from TLS:” Do you mean from all TLS, for every web site? Or for a subset of sites? I think we should definitely scope it to the latter. The consequences of HPKP-bricking your site are so high that I can’t in good conscience recommend it for any site that isn’t meant to be high security.
BTW, @ScottHelme, your example suggests you’re pinning the intermediate, which the HPKP best practices post recommends against. The recommendation is pretty oblique, I admit. But in short: Pin the roots, plus your current end-entity, plus a backup, plus roots of two other CAs. Don’t pin intermediates, they can change without warning.