On Sat, Feb 8, 2014 at 9:02 PM, Yoav Nir <[email protected]> wrote: > Hi Trevor > > The issue on the tracker is about the interaction of dynamic pins with > pre-loaded pins. The authors have written section 2.7 to address this. > > So let's bring back your points: > > * Preloaded pin stores will be periodically updated, which means > browsers will need to handle "backdated" pins, i.e. pins that are > received *after* other HPKP observations but have an "Effective Pin > Date" which is earlier. To handle these in accordance with 2.7 > requires browsers to remember "un-pinning" observations (expired pins, > max-age=0, or nonexistent HPKP headers). This is sufficiently complex > that the spec needs some treatment of it. > > * 2.7 mandates that the most recent observation from any source MUST > take priority. Browsers would not be allowed to implement other > priority rules, such as prioritizing one source over another, > prioritizing fail-open or fail-closed behavior, or anything else. I > believe this is overly restrictive. Some browsers might prefer > different policies, e.g. simpler policies that don't require tracking > "un-pinning" data.
I had a more recent email (below) which describes a simple and reasonable interaction of preloaded and dynamic pins which the current spec disallows: """ There was an item to discuss "interaction between pre-loaded and dynamic pins", and some earlier discussion: http://www.ietf.org/mail-archive/web/websec/current/msg01651.html http://www.ietf.org/mail-archive/web/websec/current/msg01833.html I think the current text in draft-08 section 2.7 is unclear about what preloaded and dynamic information the browser needs to store. Most of the draft is written as if the browser is only storing active, unexpired pins. But 2.7 seems to imply the browser stores timestamped "negative observations" such as max-age=0 observations, no-header observations, and expired pins, which will override less-recently-observed pins from different data sources (preloaded overriding dynamic, or vice versa). I could imagine simpler policies. One example: * The preload and dynamic lists contain only active, unexpired pins * The browser applies pins from both lists (i.e. if both a dynamic and preloaded pin exist for example.com, they are both applied) * The browser manufacturer can push an "override" which erases bad dynamic pins for particular hostnames. This wouldn't provide automatic overriding of (preloaded/dynamic) pins based on newer observations in a different source. But it *would* allow for explicit overriding of bad dynamic pins, which seems the most important type of overriding. It also seems much simpler. I suggest we allow such different and simpler policies. If people disagree, I'd like to hear a clearer statement of: * How exactly the current policy will work (i.e. what negative information needs to be stored and how it's used). * Why it's necessary to support automatic overriding of pins from different sources based on the newest observation? """ http://www.ietf.org/mail-archive/web/websec/current/msg01938.html Trevor _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
