> On 03 Mar 2017, at 22:25, Peter Eckersley <[email protected]> wrote: > > 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.
It be cool if e.g. Certbot would reliably do that for Let's Encrypt users, I agree. But in general it seems that there's little interest by site operators (except really big ones) to actually deploy HPKP and, even more, maintain it. It seems to me that this isn't a knowledge gap, sys admins are well aware what the consequences are if they get pins wrong. I'm not aware of any project that automates this reliably at this time. > > 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". That's very specific for a spec. Maybe OPTIONAL? Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
