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

[Chris Palmer <[e-mail]>]

On Fri, Oct 19, 2012 at 8:56 AM, Tom Ritter <[e-mail]> wrote:

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

:)

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

OK.

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

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.

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

Agreed.

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

Agreed.

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

So, whitelist. That is good.

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

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