>> 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 <[email protected]> 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
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
