Subject: [Acme] HPKP in ACME

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 13 Feb 2017 11:33:46 -0800

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?

PR to remove: https://github.com/ietf-wg-acme/acme/pull/244

---

From: Clint Wilson <[email-masked]>
Date: Mon, 13 Feb 2017 20:09:48 +0000

I would definitely support removing ", and servers SHOULD emit pinning
headers", especially because of the footgun risk you indicated, but I think
there *is* some merit in continuing to recommend support for HPKP on the
client side.

On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Alan Doherty <[email-masked]>
Date: Mon, 13 Feb 2017 20:29:10 +0000

I would concur that clients should endeavour to support

(and thusly CAs can consider using in future, when support is available in wider librarys)

but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur

but how best to word that i don't know

At 20:09 13/02/2017  Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit pinning headers", especially because of the footgun risk you indicated, but I think there is some merit in continuing to recommend support for HPKP on the client side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <<mailto:[email-masked]>[email-masked]> wrote:
>PR to remove: <https://github.com/ietf-wg-acme/acme/pull/244>https://github.com/ietf-wg-acme/acme/pull/244
>
><mailto:[email-masked]>[email-masked]

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 16 Feb 2017 16:24:56 -0500

I'm supportive of removing the server pinning headers SHOULD outright.

> but how best to word that i don't know

I don't think there's much benefit in the ACME spec discussing pinning from
a client perspective.

If the clients want to pin there isn't anything about ACME that makes the
process different than (for e.g.) using square's okhttp library to pin for
any
other HTTPS server. Am I overlooking something?

On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty <[email-masked]> wrote:

> there is some merit in continuing to recommend support for HPKP on the
> client side.
> >

---

From: Richard Barnes <[email-masked]>
Date: Thu, 16 Feb 2017 17:44:41 -0500

> other HTTPS server. Am I overlooking something?

There's nothing different.  The idea here was just to point people to some
mechanisms they could use to guard against mis-issuance.  I'm OK dropping
it if people don't like it, but I would kind of like to keep it.

Perhaps we could downgrade to MAY WISH TO
https://tools.ietf.org/html/rfc6919#section-6

>> >PR to remove: <https://github.com/ietf-wg-acme/acme/pull/244>
>> https://github.com/ietf-wg-acme/acme/pull/244
>> >

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 17 Feb 2017 12:28:41 -0500

> https://tools.ietf.org/html/rfc6919#section-6

This feels a little wishy-washy for something I think we could tie-break
without
too much delay.

Jacob, Clint, and myself all stated support for removing it. You're OK with
dropping it. I think Alan is in a similar mid-point camp. (Please weigh in
if
I'm mis-characterizing)

Does anyone else feel strongly? Can we aim for consensus for
Monday?

On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes <[email-masked]> wrote:

>> process different than (for e.g.) using square's okhttp library to pin
>> for any

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 17 Feb 2017 12:36:32 -0500

without
> too much delay.

Clearly I need to get in the habit of checking the published date on RFCs
before
reading too literally :-D Good one!

On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney <[email-masked]>
wrote:

>> There's nothing different.  The idea here was just to point people to
>> some mechanisms they could use to guard against mis-issuance.  I'm OK
>> dropping it if people don't like it, but I would kind of like to keep it.
>>

---

From: Josh Soref <[email-masked]>
Date: Fri, 17 Feb 2017 12:38:16 -0500

Fwiw, I'm slowly reviewing[1] the specification.

Personally, for this version I'd be +1 on dropping the current pinning
text.

If you wanted to go with a weak statement, I think the statements you want
are:
1. Acme clients may support key pinning.
2. If an Acme client supports pinning, it should provide a way to enable
users to drop pins.

This enables servers to experiment without saying that any will.

[1] https://github.com/jsoref/acme/tree/review

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 21 Feb 2017 10:04:21 -0500

> Does anyone else feel strongly? Can we aim for consensus for

Update four days later: one additional +1 for removal from Josh Soref.

Are the maintainers comfortable merging
https://github.com/ietf-wg-acme/acme/pull/244 ?

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Feb 2017 10:34:39 -0500

I am in favor of removing the SHOUL for HPKP.  As I said in my WG Last Call comments, I support a SHOULD for OCSP stapling.

Russ

> On Feb 21, 2017, at 10:04 AM, Daniel McCarney <[email-masked]> wrote:
> 
> Are the maintainers comfortable merging https://github.com/ietf-wg-acme/acme/pull/244 <https://github.com/ietf-wg-acme/acme/pull/244> ?
> 
> 
> On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney <[email-masked] <mailto:[email-masked]>> wrote:
> > https://tools.ietf.org/html/rfc6919#section-6 <https://tools.ietf.org/html/rfc6919#section-6>
> 
> This feels a little wishy-washy for something I think we could tie-break without
> too much delay.
> 
> dropping it. I think Alan is in a similar mid-point camp. (Please weigh in if
> I'm mis-characterizing)
> 
> On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney <[email-masked] <mailto:[email-masked]>> wrote:
> process different than (for e.g.) using square's okhttp library to pin for any
> There's nothing different.  The idea here was just to point people to some mechanisms they could use to guard against mis-issuance.  I'm OK dropping it if people don't like it, but I would kind of like to keep it.  
> 
> https://tools.ietf.org/html/rfc6919#section-6 <https://tools.ietf.org/html/rfc6919#section-6>
>  
> 
> 
>  
> 
> 
> On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty <[email-masked] <mailto:[email-masked]>> wrote:
> >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> wrote:
> >PR to remove: <https://github.com/ietf-wg-acme/acme/pull/244 <https://github.com/ietf-wg-acme/acme/pull/244>>https://github.com/ietf-wg-acme/acme/pull/244 <https://github.com/ietf-wg-acme/acme/pull/244>
> >
> ><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
> >https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
> >
> >[email-masked] <mailto:[email-masked]>
> >https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
> 
> 
> 
>