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

[Tom Ritter <[e-mail]>]

>>  On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker
>>  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.

>>  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" ]
>>  }

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

On 18 October 2012 20:40, Ryan Sleevi <[e-mail]> wrote:
>   - Should the origin of the report URI be constrained the the origin of
> the target URI?

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.

>   - 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.

>     - 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.

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

>   - If the report contains validated certificates, what should the format
> be? draft-josepfsson-pkix-textual [3] may be of normative use here.

I have no opinion.

-tom