On Fri, Oct 19, 2012 at 8:56 AM, Tom Ritter <[email protected]> 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.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
