On 27 February 2014 16:07, Daniel Kahn Gillmor <[email protected]> wrote: > On 02/27/2014 03:31 PM, Trevor Perrin wrote: >> 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-age, >> is applied to includeSubdomains), but only generates reports instead of >> hard fails. The browser would store PKP and PKP-RO pins in >> separate/parallel stores, for example setting max-age=0 for a PKP pin would >> not clear PKP-RO pins, and vice versa. >> >> 2) PKP-RO is removed from the spec. >> >> 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics >> (only check current connection). I'm not sure about the usefulness of >> that, and I worry site operators would be mislead by it. > > As someone who sometimes helps to operate and plan the operation of web > sites, i don't think the semantics of (3) are misleading, but they're > not particularly confidence-inspiring either. > > What is the goal of PKP-RO? Is the goal to encourage adoption by giving > site operators confidence in a proposed configuration or organizational > workflow?
As I believe - this. PKP-RO doesn't enforce security for a site, and while a PKP header MAY be saved for later reporting* - an attacker performing a man-in-the-middle attack can block a PKP-RO assignment or a PKP-RO report. (At least, right now, I have a suggestion for this below.) * From http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3 So I feel it's primarily for testing a configuration and gaining confidence in it before rolling it out. > The real footgunnery with PKP will come during key transition/rollover > (or switching CAs), as clients who have cached pins cope with the > changes. Using (3)-style PKP-RO to build confidence in an > organizational workflow around this kind of transition event doesn't > seem possible. I agree. So I'm for #1 - store it. I have afew suggestions around fixing up portions of the doc for this. The PKP-RO header MUST be able to be cleared out at any time by setting max-age=0 if the connection occurs over an error-free TLS connect excepting any requirement of matching a key to a PKP-RO header. Explained, I should be able to clear out an old PKP-RO header even if I set the hash to DEADBEEF and the max-age to a year. The PKP-RO header reports MAY be stored for reporting at another time. I don't think browsers will implement this right away, but down the line I think it might turn into an actual security feature. A report SHOULD be generated and transmitted (or stored) before clearing out an old policy. (So bad is I get an extra report I ignore, good is that an attacker can't definitively silence a report if it is stored for later.) When I recieve reports, I can tell what the PKP-RO policy was at the time by examining the report. Except that the report needs to have a new field in there saying if it's mode is 'enforcement' or 'report-only'. As a site operator, I can even go farther by specifying a non-hash such as sha256=policytest20140301v1 - no one will be able to gen a cert that hashes to a b64 representation of that, and it lets me track my policy deployments if I like. -tom _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
