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

["Ryan Sleevi" <[e-mail]>]

On Fri, October 19, 2012 8:56 am, Tom Ritter wrote:
<snip>
> >   - 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.
>
> >   - 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?
>
>  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.
>
<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.