On Fri, Mar 03, 2017 at 11:53:49AM +0000, Aaron Zauner wrote: > > > On 13 Feb 2017, at 19:33, Jacob Hoffman-Andrews <[email protected]> wrote: > > > > Martin brought up a section I've been considering removing: > > > >> Clients SHOULD support HTTP public key pinning [RFC7469], and servers > > SHOULD emit pinning headers. > > > > Here's my reasoning: > > > > - Public key pinning isn't implemented in most HTTPS libraries outside > > of browsers, so this is a considerable burden on implementers. > > - Public key pinning carries a fairly high risk of footgunning. The > > consequence of a failed pin for a CA that serves many ACME clients would > > be that some of those clients would fail to renew their certs, causing > > cascading breakage. > > - There is relatively little confidential information conveyed in ACME, > > and there are other defenses built into ACME (like including the account > > key as part of the challenge data), so HPKP is not strongly necessary. > > > > Any objections? > > I was the person who initially suggested adding HPKP, that was more than two > years ago. People get HPKP headers wrong constantly and thus lock themselves > or their users out of services, missing library support is - as you point > out - a problem and I don't see much interest within the community to add > HPKP. By now I consider HPKP failed tech. to be honest.
I don't think we should give up on HPKP completely just yet; the thing that's missing for site operators is a better toolchain for getting it right that protects against errors by humans in the loop. As for how much it's useful for ACME itself -- I think the big gating variable would be getting better support for it into various languages' HTTP libraries. It would make sense to have it built into Go, Python's requests module, etc. If that happened, ACME servers SHOULD use it. It probably doesn't make sense for ACME clients to be trying to bolt their own HPKP logic onto their language's HTTP library. I'm agnostic about whether the wording should be struck from the draft or changed to be "clients SHOULD support HTTP public key pinning if the libraries they depend on can provide it". -- Peter Eckersley [email protected] Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
