On Thu, Feb 13, 2014 at 3:56 AM, Yoav Nir <[email protected]> wrote: > [ I'm forking the thread so as to avoid confusing it with the other issue ] > > Section 2.7 ( > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.7 ) > describes the interaction between pre-loaded pin lists and the dynamic pins > that the UA observes. > > The draft says that any later observation (new pin, unpin, missing pin) > always trumps an earlier observation. Seems right, except this creates an > interesting issue with updates to the pre-loaded pin list, such as when there > are browser updates, or just a dynamic update from the list: > - what happens if a pin in the fresh list differs from a dynamic pin? > - what happens if a pin that is in the list is one that had been unpinned > before? > > One way is to require the static list to have "observation dates" for each > entry, and also require the UA to keep track of all noted pins for the > lifetime of that pin. By keeping track I mean recording all replacement and > unpinning events, including dates, so as to be able to construct a timeline > with the static list, and be able to tell which event happened last. For > example, if the UA notes a pin on 1-Feb, then notes an unpinning on 9-Feb, > then on 15-Feb it downloads a new list with the old pin observed at 7-Feb, > the pin should remain deleted.
Almost, but note that an unpinning event might be an observation of a max-age=0 header, *or* a pin expiring (in which case the browser would need to keep remembering the expired pin for some period along with the time of last observing the header, *not* the expiration date). So in your example - if the "unpinning" on 9-Feb is an HPKP observation of max-age=0 then it would trump the preloaded pin's 7-Feb observation date, but if it was an expiration of an 8-day pin it would not, it would only trump preloaded observations prior to 1-Feb... > Another way is to treat all updates from the static pins as if they had just > been observed at the moment of download. That is obviously much easier to > implement. Seems fine, as long as the duration of those pins does not exceed what the site has asserted. > A third way (Trevor's) is to treat the static and dynamic pins as two > separate pin databases, both of which are enforced and no interaction between > them. But the UA vendor can also push updates for deleting dynamic pins, to > save web site operators who have shot themselves in the foot. Yeah, I think this ability to un-pin sites who screw up will (sadly) probably be necessary. > Yet a fourth way is to observer that none of this affects interoperability in > any way and leave it up to the UA vendor to choose their way. The web site > operator should only include valid pins in their HPKP headers, and they > should also enter only valid pins in pre-loaded lists. They should also deal > with the fact that don't control usage patterns, so anytime they pin > something for X seconds, their website MUST conform to that pin for at least > those X seconds or bad things will happen. Your "fourth way" is well-put, and I agree - all of these seem valid implementations which should be allowed. Trevor _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
