Subject: [websec] #54: Specify a report-only mode

From: "websec issue tracker" <[email-masked]>
Date: Thu, 18 Oct 2012 23:56:58 -0000

#54: Specify a report-only mode

 Should there be a "report-only" mode, allowing site operators to see how
 using HPKP would affect their site's operation in browsers supporting
 HPKP? (Probably.)

 If so, specify how that mode would work.

-- 
-------------------------+----------------------
 Reporter:  palmer@…     |      Owner:  palmer@…
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  key-pinning  |    Version:
 Severity:  -            |   Keywords:
-------------------------+----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/54>
websec <http://tools.ietf.org/websec/>

---

From: "websec issue tracker" <[email-masked]>
Date: Thu, 18 Oct 2012 23:57:16 -0000

Changes (by palmer@…):

 * status:  new => assigned

-- 
-------------------------+-----------------------
 Reporter:  palmer@…     |       Owner:  palmer@…
     Type:  defect       |      Status:  assigned
 Priority:  major        |   Milestone:
Component:  key-pinning  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/54#comment:1>
websec <http://tools.ietf.org/websec/>

---

From: Chris Palmer <[email-masked]>
Date: Thu, 18 Oct 2012 17:17:56 -0700

>  If so, specify how that mode would work.

What are people's thoughts on this? The motivation for a report-only
mode is twofold: (1) site operators want to see what would happen
before going live with pinning; and (2) site operators often don't
know all their keys, or all their intermediate signers' keys, or all
their trust anchors' keys, and a reporting mode could help them find
out.

(2) implies that the reporting interface would have to allow the UA to
tell the site not just "pin validation succeeded/failed", but also why
(probably by simply reporting the entire validated certificate chain
that the UA computed/observed).

The reporting interface must be one that is easy for site operators to
implement — writing code to collect the reports should not be a huge
burden for developers. Perhaps a simple JSON blob:

{
  "pin-validation-succeeded": (true|false),
  "expected-pins": [ "sha1/blahblah", "sha256/foobar", ... ],
  "validated-chain": [ "PEM blob of EE", "PEM blob of intermediate",
..., "PEM blob of anchor" ]
}

The next issue is, should the site be able to specify a URL to which
the UA will POST the JSON blob, or should we specify a single,
well-known URL path? Using a well-known path seems simpler and less
error-prone generally.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 18 Oct 2012 17:40:42 -0700

>  well-known URL path? Using a well-known path seems simpler and less

To wit, this was also brought up by several people during the IETF 84
presentation.

As an example of how such behaviour might be specified, a similar
report-only mode is implemented with Content Security Policy [1]. In CSP,
both the "Content-Security-Policy" and the
"Content-Security-Policy-Report-Only" headers may be present, both are
considered, and both may contain independent/conflicting policies.

In CSP, one of the token/directives is "report-uri", which indicates the
URI to use to send violation reports to, as well as a defined format for
what the contents of the report should contain.

The distinction here between PKP and CSP is that CSP is evaluated
per-resource load within a web origin, whereas PKP is enforced at the
transport layer. A PKP violation is nominally detected during the TLS
handshake, and depending on client implementation, may either be treated
as an error during the TLS handshake or immediately following it, prior to
using the connection to transmit the (original) HTTPS request.

If a report-only mode is supported, the following considerations should be
worked out:
  - Should the origin of the report URI be constrained the the origin of
the target URI?
  - Should the report URI be allowed to specify HTTPS?
  - If the report URI specifies HTTPS, and the report URI origin is the
same as the target URI, but the report URI violates either the PKP or
PKP-Report-Only policy, should the report still be submitted?
    - Is there a blacklist or whitelist of headers that should be used to
prevent against abuse or compromise. For example, presumably including
cookies in the report submission for an invalid PKP over the same
connection that generated the invalid PKP would be bad, as it may
(will) lead to the compromise of the users' data.
  - If the report contains validated certificates, what should the format
be? draft-josepfsson-pkix-textual [3] may be of normative use here.

[1]
http://www.w3.org/TR/CSP/#content-security-policy-report-only-header-field
, with the expired, less-comprehensive draft submitted to IETF at
http://tools.ietf.org/html/draft-gondrom-websec-csp-header-00#section-4.2
[2] http://www.w3.org/TR/CSP/#report-uri
[3] http://tools.ietf.org/html/draft-josefsson-pkix-textual

---

From: Tom Ritter <[email-masked]>
Date: Fri, 19 Oct 2012 11:56:55 -0400

>>  What are people's thoughts on this?

It hurts me to say so, because it's going to be more work and
complication and delay - but I agree a reporting system should be
added.

>>  ..., "PEM blob of anchor" ]

I like this, although I would include the entire PKP header, the Host
header, and request URI.

>   - Should the origin of the report URI be constrained the the origin of

No, you should be allowed to specify a third party domain.  I could
easily see a third party service collecting these reports as a free or
paid service.  Google Webmaster Tools may even grow into collecting it
and CSP violations.

>   - Should the report URI be allowed to specify HTTPS?

Yes.  This is potentially sensitive information, and we would like it
to be protected in transit.

> PKP-Report-Only policy, should the report still be submitted?

Honestly I don't see why not.  If it is an attacker, the attacker will
know the user rejected the TLS connection, and will have a good idea
it was because of pinning.  So what's the harm in telling them the
additional information.  Vs if it is a legit screw-up by the site,
they would still like to have the information.

> (will) lead to the compromise of the users' data.

I don't think any headers other than the PKP, Host, and URL would be needed.

> be? draft-josepfsson-pkix-textual [3] may be of normative use here.

I have no opinion.

-tom

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 19 Oct 2012 09:10:21 -0700

On Fri, October 19, 2012 8:56 am, Tom Ritter wrote:
<snip>
>  they would still like to have the information.
<snip>

I should have mentioned the other scenario that is closely related, which
is that independent of whether the report URI is different than the target
URI, what to do when the report URI violates its own PKP/PKP-Report-Only
policy.

The concern I have here is the disconnect between expectations. If the
site operator specifies HTTPS for a Report URI, presumably, they expect
exactly what you mentioned - that sensitive information will be protected
in transit.

If Report URIs fail the (previously stored) PKP policy, should the report
still be submitted or not? Does it match site author expectation?

A related, but subtle, implementation issue that is expected to arise if
HTTPS is allowed is ensuring that reporting loops are not formed. For
example, if submitting a report over HTTPS (via POST, presumably), and the
response data includes a PKP which the current connection violates, and a
report URI for the same URI as what was just posted, should the new
violation be reported? This can occur when the Report URI is independent
of the initial Target URI (so the second report would be unique) and when
the Report URI is identical to the Target URI (so the second report is
redundant).

My reaction to all of this is that, when the PKP header is received
following the submission of a report, that the PKP header is ignored.

This is just some of the complexity with report URIs that will need to be
worked out - although I agree with your responses, and I agree that, even
for the complexity brought, it seems like it will be a necessary and
useful part of policy configuration.

---

From: Chris Palmer <[email-masked]>
Date: Fri, 19 Oct 2012 14:29:14 -0700

> complication and delay - but I agree a reporting system should be

:)

> I like this, although I would include the entire PKP header, the Host

OK.

> paid service.  Google Webmaster Tools may even grow into collecting it

I think we should follow precedent, i.e. CSP, and allow aribtrary
report URIs. This too hurts me to say. :) But consistency with
existing specifications and implementations is preferable to inventing
a new behavior for a similar feature.

> to be protected in transit.

Agreed.

> they would still like to have the information.

Agreed.

> I don't think any headers other than the PKP, Host, and URL would be needed.

So, whitelist. That is good.

>> be? draft-josepfsson-pkix-textual [3] may be of normative use here.

draft-josepfsson-pkix-textual works fine for me.