Sigh, the silence is deafening. Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer? If not, we'll resolve it that way.
Note, however, that the authors cannot update the draft until IETF week, but we can gather the required changes. Please respond. Thanks, Yoav On Feb 13, 2014, at 9:42 PM, Trevor Perrin <[email protected]> wrote: > 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
