[Replying to myself, but with no hats on] IMO the current text is fine. Regarding the first point, it creates a burden for the browser maker, but only if they update their pre-loaded pin list by observation. If it's created by OOB means as described in the second example, the burden is on the site operators, and they are likely to unpin in both places at the same time. I think this also goes to your second point.
I think in a future where HPKP is supported in most browsers, pre-loaded lists will contain very few entries - perhaps the big content sites and a few banks, maybe Paypal. I expect that most site operators would be happier to pin sites by themselves with an HPKP header rather than interact with all browser vendors. Yoav On Feb 9, 2014, at 7:02 AM, 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. > > Section 2.7 is pasted below my sig. > > > Yoav > > > 2.7. Interactions With Preloaded Pin Lists > > > UAs MAY choose to implement additional sources of pinning > information, such as through built-in lists of pinning information. > Such UAs SHOULD allow users to override such additional sources, > including disabling them from consideration. > > UAs that support additional sources of pinning information MUST use > the most recently observed pinning information when performing Pin > Validation for a host. The most recently observed pinning > information is determined based upon the most recent Effective Pin > Date, as described in Section 2.3.2 > . > > If the result of noting a Valid Pinning Header is to disable pinning > for the host, such as through supplying a max-age directive with a > value of 0, UAs MUST allow this new information to override any other > pinning data. That is, a host must be able to un-pin itself, even in > the presence of built-in Pins. > > Example: A UA may ship with a pre-configured list of Pins that are > collected from past observations of Valid Pinning Headers supplied by > hosts. In such a solution, the pre-configured list should track when > the Valid Pinning Header was last observed, in order to permit site > operators to later update the value by supplying a new Valid Pinning > Header. Updates to such a pre-configured list should not update the > Effective Pin Dates for each host unless the list vendor has actually > observed a more recent header. This is to prevent situations where > updating the Effective Pin Date on a pre-configured list of Pins may > effectively extend the max-age beyond the site operator's stated > policy. > > Example: A UA may ship with a pre-configured list of Pins that are > collected through out-of-band means, such as direct contact with the > site operator. In such a solution, the site operator accepts > responsibility for keeping the configured Valid Pinning Header in > sync with the vendor's list, allowing the UA vendor to have each > update to the list be treated as as an update of the Effective Pin > Date. > > > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
