Subject: Re: [Acme] HPKP in ACME

From: Aaron Zauner <[email-masked]>
Date: Fri, 3 Mar 2017 11:53:49 +0000

> On 13 Feb 2017, at 19:33, Jacob Hoffman-Andrews <[email-masked]> 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.

+1 on removing the section entirely.

Aaron

> 
> PR to remove: https://github.com/ietf-wg-acme/acme/pull/244
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Peter Eckersley <[email-masked]>
Date: Fri, 3 Mar 2017 14:25:02 -0800

On Fri, Mar 03, 2017 at 11:53:49AM +0000, Aaron Zauner wrote:
> 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-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 4 Mar 2017 11:24:36 +0000

> On 03 Mar 2017, at 22:25, Peter Eckersley <[email-masked]> wrote:
> 

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.

> they depend on can provide it".

That's very specific for a spec. Maybe OPTIONAL?

Aaron

---

From: Nadim Kobeissi <[email-masked]>
Date: Tue, 7 Mar 2017 13:13:12 +0100

> On Mar 4, 2017, at 12:24 PM, Aaron Zauner <[email-masked]> wrote:
> 
> 

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

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 8 Mar 2017 13:46:34 +0000

> On 07 Mar 2017, at 12:13, Nadim Kobeissi <[email-masked]> wrote:
> 
>> 

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 sud…

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.

> 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 H…

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