HPKP Public-Key-Pins Header

[deis-admin]

From @wenzowski on June 18, 2015 19:48

If an etcd flag were to enable nginx to serve HPKP headers...

1. Should Deis automatically extract the pin-sha256 for each public key configured in etcd?
2. Should Deis expose a unified report-uri to collect pinning failure reports from User-Agents?

HPKP is covered by RFC 7469 and there's a summary on MDN

Copied from original issue: deis/deis#3899

[deis-admin]

From @croemmich on June 18, 2015 20:21

Should Deis automatically extract the pin-sha256 for each public key configured in etcd?

That would be my preference. You could maybe allow it to be manually set per domain with etcd keys, but that adds another level of complexity.

Should Deis expose a unified report-uri to collect pinning failure reports from User-Agents?

I don't think Deis should implement the endpoint to collect failures, but maybe allow a url to be set in an etcd key? That way people can implement it if they chose to.

[deis-admin]

From @technosophos on June 19, 2015 16:51

Regarding question 2, how vital is a functioning report-uri to the overall success of HPKP?

[deis-admin]

From @wenzowski on June 19, 2015 18:16

If the ops team doesn't have a monitored endpoint to collect client failures, HPKP becomes a black box that prevents an unknown portion of connection attempts.

[deis-admin]

From @wenzowski on June 19, 2015 18:21

...validation failures are documented in section 3

[deis-admin]

From @tdelmas on June 21, 2015 17:21

report-uri is optional, but a backup key (a key NOT in the current chain) is mandatory : The given set of Pins MUST contains at least one Pin that does NOT refer to an SPKI in the certificate chain. https://tools.ietf.org/html/rfc7469#section-4.3

[deis-admin]

From @technosophos on July 17, 2015 21:10

I think that (1) in the original post is something we should pursue. The feature is not currently on the roadmap, but I think we'd happily look at any PRs that did this.

Based on @tdelmas's clarification, I'm not sure what (for us) the best practices should be for the backup key. My interpretation of section 4.3 suggests that this key is something we'd have to deliver to the deis client at some point to be stored locally on the developer's workstation.

For convenience, here's the paragraph in question:

   The primary way to cope with the risk of inadvertent Pin Validation
   failure is to keep a Backup Pin.  A Backup Pin is a fingerprint for
   the public key of a secondary, not-yet-deployed key pair.  The
   operator keeps the backup key pair offline, and sets a pin for it in
   the PKP header.  Then, in case the operator loses control of their
   primary private key, they can deploy the backup key pair.  UAs, who
   have had the backup key pair pinned (when it was set in previous
   Valid Pinning Headers), can connect to the host without error.

(The reasoning for offline storage is explained in the following paragraph.)

I'd like to have a solid understanding of what the best practice for dealing with the backup key is. Is this something that the platform user(s) need to be aware of? Practically speaking, whose responsibility is it?

Finally, there's the matter of report-uri. From 2.1.4:

   Note that the report-uri need not necessarily be in the same Internet
   domain or web origin as the host being reported about.

So should we expose this on a Deis core service and collect data for all apps hosted? What would the tooling around this look like?

I suppose the big underlying question is really this: Who are the "users" of this functionality? The platform maintainers (deisctl) or the platform users (deis).

[krancour]

Workflow's (v2's) router no longer proxies etcd like v1 did, as no Workflow component has a direct dependency on etcd. Closing this as inapplicable to our current state.