Subject: [websec] Public-Key-Pins-Report-Only - attempt at summary

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Feb 2014 18:30:39 +0200

Hi

I think all the issues raised during this WGLC have been (I think) addressed (and correct me on another thread if I’ve missed something), with the exception of some issues with the Report-Only header.

First issue was the interaction between PKP and PKPRO if both are present. Current text ([1]) says “If a Host sets both the Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin Validation”.  This was objected to by some ([2[), as it doesn’t follow the CSP model. Chris suggested alternative text that allows them both ([3]), where PKP is enforced, and PKPRO is only noted and reported. There were no objections to this, except that Tom corrected a typo. Can we consider this resolved?

Then Trevor brought up another issue ([4]). He asked whether the UA actually notes PKPRO pins or just reports on them. Nobody has responded yet, but I think that’s a good point. Is there any value to noting PKPRO for, say, a month, and then reporting after two weeks that the current certificates do not match?  When I imagine how someone would use PKPRO, I guess they generate a pins string, issue them as PKPRO, and if no reports arrive for, say, 7 days, they are moved into “production”, which is the regular PKP. Suppose the pins in PKPRO do generate reports, I guess the administrator checks the reports, fixes whatever is wrong, and posts the good pins as PKPRO again. Does it make sense to keep receiving reports for the old pins?  OTOH if we accept the non-noting idea, then the max-age directive makes no sense and should be omitted.  As there has been no discussion yet, we need to consider this a bit. 

Please do.

Yoav & Tobias

[1] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3
[2] http://www.ietf.org/mail-archive/web/websec/current/msg02001.html
[3] http://www.ietf.org/mail-archive/web/websec/current/msg02026.html
[4] http://www.ietf.org/mail-archive/web/websec/current/msg02030.html

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 26 Feb 2014 09:20:34 -0800

On Wed, Feb 26, 2014 at 8:30 AM, Yoav Nir <[email-masked]> wrote:

> Hi
>
> I think all the issues raised during this WGLC have been (I think)
> addressed (and correct me on another thread if I've missed something), with
> the exception of some issues with the Report-Only header.
>

I don't know whether the recently-discussed issues are addressed, as we
haven't seen a new draft.

Many of the issues I raised in July and November are still outstanding:

http://www.ietf.org/mail-archive/web/websec/current/msg02011.html
http://www.ietf.org/mail-archive/web/websec/current/msg01956.html
http://www.ietf.org/mail-archive/web/websec/current/msg01692.html

I'll bring them up again once there's a new draft.

> First issue was the interaction between PKP and PKPRO if both are present.
> Current text ([1]) says "If a Host sets both the Public-Key-Pins header and
> the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin
> Validation".  This was objected to by some ([2[), as it doesn't follow the
> CSP model. Chris suggested alternative text that allows them both ([3]),
> where PKP is enforced, and PKPRO is only noted and reported. There were no
> objections to this, except that Tom corrected a typo. Can we consider this
> resolved?
>

No, because this is linked to the question about how PKP-RO works, which we
don't have an answer to:

http://www.ietf.org/mail-archive/web/websec/current/msg02030.html

> Then Trevor brought up another issue ([4]). He asked whether the UA
> actually notes PKPRO pins or just reports on them. Nobody has responded
> yet, but I think that's a good point. Is there any value to noting PKPRO
> for, say, a month, and then reporting after two weeks that the current
> certificates do not match?  When I imagine how someone would use PKPRO, I
> guess they generate a pins string, issue them as PKPRO, and if no reports
> arrive for, say, 7 days, they are moved into "production", which is the
> regular PKP. Suppose the pins in PKPRO do generate reports, I guess the
> administrator checks the reports, fixes whatever is wrong, and posts the
> good pins as PKPRO again. Does it make sense to keep receiving reports for
> the old pins?  OTOH if we accept the non-noting idea, then the max-age
> directive makes no sense and should be omitted.  As there has been no
> discussion yet, we need to consider this a bit.
>

The issue is not just old pins, it's whether the browser is expected to the
apply the PKP-RO check to other connections besides the current one, and if
so, how these two different types of pins co-exist, whether they overwrite
each other, etc.

Trevor

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 26 Feb 2014 13:44:20 -0800

>  I'll bring them up again once there's a new draft.

If there are outstanding issues, we definitely want to be tracking them in
the issue tracker.

The threads you link to include several issues that should be resolved
now. While I appreciate you linking to them, it would be helpful to make
sure what you feel is outstanding is properly noted.

>  so, how these two different types of pins co-exist, whether they overwrite

In attempt to resolve your outstanding issue(s) with PKP-RO, I want to
first ensure that this proposal makes sense. If we're in agreement, we can
work on adding it to the next draft.

PKP
  - Persistently recorded
  - Expires based on max-age
  - Causes all subsequent connections since 'noting' fails
    - Note that this is somewhat ambiguous within a UA that has multiple
simultaneous connections, and for which header parsing may happen at
any arbitrary time.
    - _HOWEVER_, I think this is best left up to implementations, since
the external effects are consistent with how the server/service sets
up resource fetching.

PKP-RO
  - Not persistent
  - Applies only to the _single_ transport connection
  - Because HTTP connections MAY be kept-alive or re-used, to further qualify
    - Is evaluated upon receipt of the header, for the response it's
included in.

This means that if an HTTPS server sends PKP-RO header, then performs a
TLS renegotiation that changes certificates in a way that violates the
-RO, _NO_ report is sent. If the connection is used for another HTTP
request, and -RO is sent, then the policy IS re-evaluated and a report is
sent.

Clarify that PKP-RO does _not_ affect the overall security state of the
resource fetch. Specifically, it does NOT cause the connection to be
closed with error. UAs MAY choose to also notify the user on -RO failures,
or MAY NOT - it's up to the implementation. Example of "notification" may
include something as simple as logging to the developer console.

Cheers,
Ryan

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 26 Feb 2014 15:05:11 -0800

>     - Is evaluated upon receipt of the header, for the response it's

That's the simpler of the options.

It means PKP-RO only tests whether the browser builds a chain you expect at
one moment in time.  It doesn't test whether the site is serving the
correct certs for different URLs (e.g. includeSubdomains), so it's not a
thorough test (i.e. the lack of reports doesn't provide much confidence
that the PKP header is safe).

It also doesn't have any security value.

I don't hugely object to this, but given its limitations I'm not sure it's
worth the effort.

Curious what other people think.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Feb 2014 11:44:34 +0200

> include something as simple as logging to the developer console.

I (with no hats) am very much in favor of this change.  It makes sense for the way I think this will be used. If I were administrating a web server and wanted to use PKP, I would generate the PKP string and install it as PKP-RO for a few days. If no reports came in, it would be ready for production. I am not concerned about the renegotiation issue. 

[with chair hat] if others feel differently, please speak up now.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Feb 2014 11:51:21 +0200

On Feb 27, 2014, at 1:05 AM, Trevor Perrin <[email-masked]> wrote:

> 
> On Wed, Feb 26, 2014 at 1:44 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> It means PKP-RO only tests whether the browser builds a chain you expect at one moment in time.  It doesn't test whether the site is serving the correct certs for different URLs (e.g. includeSubdomains), so it's not a thorough test (i.e. the lack of reports doesn't provide much confidence that the PKP header is safe).
>   
> I don't hugely object to this, but given its limitations I'm not sure it's worth the effort.
> 

Not much for security, because anyone who can mess with the certificates that you’re seeing can also mess with HTTP headers. But it does provide a good mechanism for the administrator to avoid shooting himself in the foot. 

For example, if the administrator wants to use the pin-sha4 directive from the other thread and one of the browsers and some browsers doesn’t support this directive, then having the SHA-4 pins in PKP-RO for a few days will generate some reports, and the administrator might decide that it’s not yet time to move to SHA-4.

Another example, if the administrator calculated the has wrong (like hashing all the certificate rather than SPKI) they will also get reports. 

Unfortunately is doesn’t help with the issue of replacing the certificate with one whose chain is not covered by the pins - that’s the one that bricks your site. PKP-RO does not help this, but it still has some value.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 27 Feb 2014 09:52:12 -0800

On Thu, Feb 27, 2014 at 1:44 AM, Yoav Nir <[email-masked]> wrote:
>
>
> I (with no hats) am very much in favor of this change.  It makes sense for
> the way I think this will be used. If I were administrating a web server
> and wanted to use PKP, I would generate the PKP string and install it as
> PKP-RO for a few days. If no reports came in, it would be ready for
> production.

Not necessarily.

This type of PKP-RO would *NOT* detect whether all your subdomains or
load-balancers / front-end machines are correctly configured with the right
certs.

If people do what you suggest, they could easily get a false impression
that they're ready to go live ("no reports - it must be good!"), and screw
up their site.

Trevor

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 27 Feb 2014 12:15:27 -0800

>  that they're ready to go live ("no reports - it must be good!"), and screw

Do you have any alternatives you would like to suggest? That might save a
few feedback cycles.

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 27 Feb 2014 12:31:00 -0800

> Do you have any alternatives you would like to suggest? That might save a

The alternatives I see are:

1)  PKP-RO implements the full PKP semantics (i.e. is stored for max-age,
is applied to includeSubdomains), but only generates reports instead of
hard fails.  The browser would store PKP and PKP-RO pins in
separate/parallel stores, for example setting max-age=0 for a PKP pin would
not clear PKP-RO pins, and vice versa.

2)  PKP-RO is removed from the spec.

3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics
(only check current connection).  I'm not sure about the usefulness of
that, and I worry site operators would be mislead by it.

Trevor

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 Feb 2014 16:07:39 -0500

> that, and I worry site operators would be mislead by it.

As someone who sometimes helps to operate and plan the operation of web
sites, i don't think the semantics of (3) are misleading, but they're
not particularly confidence-inspiring either.

What is the goal of PKP-RO?  Is the goal to encourage adoption by giving
site operators confidence in a proposed configuration or organizational
workflow?

The real footgunnery with PKP will come during key transition/rollover
(or switching CAs), as clients who have cached pins cope with the
changes.   Using (3)-style PKP-RO to build confidence in an
organizational workflow around this kind of transition event doesn't
seem possible.

	--dkg