> On Mar 4, 2017, at 12:24 PM, Aaron Zauner <[email protected]> wrote: > > >> 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.
The nice thing about HPKP is that it allows site operators to do a strong assert on the authenticity of a bunch of certificates aside from the current one. As far as I know, this is the only simple currently available mechanism that would allow site operators to suddenly switch certificate and even certificate authorities without that switch being sudden and not backed up by some publicly verifiable chain of authenticity. Another cool side-note is that this chain of authenticity, if maintained throughout a bunch of HPKP-backed certificate rotations, becomes controlled more by the site operator themselves than the CA, which is interesting. Specifically since it is possibly the unique mechanism in which this can be accomplished, I think it deserves being kept for future integration, or at least not discounted so early on. In my mind, HPKP integration into ACME is a matter of pooling engineering time. Integration can wait until, say, Let’s Encrypt engineers feel they have time on their hands, but the entire idea of HPKP shouldn’t be put down prematurely. It has unique potential. Nadim > >> >> 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 > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
