> On 07 Mar 2017, at 12:13, Nadim Kobeissi <[email protected]> wrote: > >> >> 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.
Yea, again: I was the person that proposed adding HPKP in the first place. > 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. I think you're confusing HPKP with TACK. TACK had unique potential (especially for having more control on [perceived] trust for site operators). HPKP is a dummbed-down version of TACK fitted for HTTP headers, which turns out to have almost zero deployment. I'm not saying that TACK would have been the ultimate thing that would have gotten wide-spread deployment, but it would certainly have been easier to integrate that from the beginning with -- say -- server daemons and just deploy it via package upgrades. It's also much less likely that operators will DoS their services by mis-using pins with TACK. > > 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. Anyway, I feel that discussion on the whole topic isn't really productive anymore here. We all agree that HPKP has it's problems and there doesn't seem to be a timeline for integration in Certbot. As for the ACME spec.: I think we could go with OPTIONAL, but I have no problems with removing the paragraph. Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
