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