On Fri, Feb 7, 2014 at 5:47 PM, Chris Palmer <[email protected]> wrote: > Oops, I forgot one thing: > > On Fri, Feb 7, 2014 at 5:12 AM, Tom Ritter <[email protected]> wrote: > >> "If a Host sets both the Public-Key-Pins header and the Public-Key- >> Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and >> MUST note only the pins and directives given in the Public-Key-Pins- >> Report-Only header." >> >> I thought we were following the CSP model, where you can enforce one >> policy, but test a second. > > Honestly, I think that's likely to be too complicated. I want to > prioritize ease of deployment (which includes a simple-to-state policy > like the above, and failing open when not unreasonably unsafe), and > I'd like for the implementation not to get too much more complicated.
When we discussed PKP-RO in Nov/Dec there was uncertainty on things like: * Is the browser expected to store a PKP-RO pin, or just evaluate it against the connection that asserted it? * What happens when a server asserts both PKP and PKP-RO? The first seems like a major decision which hasn't been decided yet. On the second point, Ryan Sleevi's opinion back then was different from yours: "A PKP might specify a looser-policy, while PKP-Report-Only is used to test a more restrictive policy for deployment." http://www.ietf.org/mail-archive/web/websec/current/msg01961.html It seems you've decided differently. But that brings back an earlier question: if the PKP and PKP-RO headers can't be usefully asserted simultaneously, why have two headers at all? Shouldn't we just have a "read-only" directive in that case? In any case, the -10 and -11 drafts didn't make any clarifications to PKP-RO, so are these still open issues? There were a few other things Ryan was going to clarify about PKP-RO. Below are excerpts from that thread: http://www.ietf.org/mail-archive/web/websec/current/msg01961.html [TREVOR] Why is there a "Public-Key-Pins-Report-Only" header instead of a "report-only" directive? Most of the document is written as if there was a single "PKP header field", so a directive would make more sense. [SLEEVI] Similar to CSP. A PKP might specify a looser-policy, while PKP-Report-Only is used to test a more restrictive policy for deployment. ... Report-Only doesn't/wouldn't need to be stored, because it is a report-only mechanism. You simply evaluate the R-O on the current connection (if a directive is present) and ping back. ... To me, R-O makes most sense when treated like CSP - if present, report, otherwise, nothing. This is consistent with an implicit Max-Age: 0, because no storage is required or performed. [TREVOR] Hmm, I assumed "report-only" pins would be noted, and the draft seems written that way. **************************** [TREVOR] Section 2.5 - Does a failed validation of a "report-only" pin count as an "error" that will inhibit noting of new pins in the connection? [SLEEVI] No. Happy to clarify that. **************************** [TREVOR] Specified UA behavior with multiple header fields is contradictory: - 2.1.3: "If a Host sets both the Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and MUST note only the pins and directives given in the Public-Key-Pins-Report-Only header." - 2.3.1: "If a UA receives more than one PKP header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field." [SLEEVI] The ambiguity is the term "PKP header field", which may be alternatively written "more than one PKP header field or more than one PKP-R-O header field". Does that satisfy your concern? Trevor _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
