On Wed, May 22, 2013 2:46 pm, Tobias Gondrom wrote: > On 22/05/13 22:21, Yoav Nir wrote: > > Hi, Tobias > > > > On May 23, 2013, at 12:02 AM, Tobias Gondrom > > <[email protected] <mailto:[email protected]>> wrote: > > > > <snip /> > > > >>> On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom > >>> <[email protected] <mailto:[email protected]>> > >>> wrote: > >>> > >>> > >>> as mentioned before: I believe a time limit of 1 month is too > >>> short > >>> considering that some of the high profile use cases (banks, > >>> etc.) may > >>> only have monthly or bi-monthly usage. In which case the key pin > >>> would > >>> regularly expire before people return to the site and the > >>> protection is > >>> null. > >>> > >>> > >>> You're assuming that pin assertions (like HPKP headers) are only > >>> processed by individual browsers. > >>> > >>> I hope pin assertions will *also* be processed by web crawlers to > >>> create pin lists which are made available to browsers (via preloaded > >>> lists, secure links, online lookups, etc.) > >>> > >>> In that case, having pins last a month (instead of shorter) keeps > >>> the frequency of re-crawling sites and re-downloading pin lists > >>> manageable. Longer pins wouldn't be a big improvement.# > >> > >> The web crawler idea could be interesting as a solution to early pin > >> expiry if we would have a hard limit in the RFC, but only if _all_ > >> browsers will implement and use them. Which from my current > >> understanding is not on the horizon. At least I have seen no such > >> indications. Otherwise you get the varying implementations through > >> "creative approaches" you are worried about down below (and which I > >> don't like either). > >> > >> And maybe a question to go a step further: > >> Would you agree that if we would do a 30-day hard limit as you > >> propose, this would basically mean that all less frequent > >> banking/paypal/... users MUST (or a very strong SHOULD) use such a > >> web crawler to make sure that their pin has not expired before they > >> come back? > >> This would be a big problem in my eyes, as IMHO this assumption can > >> not be guaranteed nor expected to be rolled out consistently. > > > > There is an alternative to the web crawler (although the crawler would > > be better). Your browser could refresh the pins in the background. If > > the pin is about to expire (say, in 7 days) and you have an Internet > > connection, the browser can silently open a connection to the server, > > see that the SSL handshake fits the pin, and refresh the entry in the > > local pin database. This won't scale very well if every site on the > > Internet has pins, but I don't really expect anyone to note more than > > several tens of pins (banking sites, some government, maybe things > > that accept credit cards). With less than 100 sites, you can make do > > with noting 3-4 pins per day, which shouldn't consume too much traffic. > > Interesting idea. > And could this maybe also solve Trevor's concerns? > > E.g. we could add to the spec some implementation advise, like "even if > the user does not visit the pinned sites, the browser SHOULD attempt in > the background to refresh recognized pins if they are about to expire or > before 30 days have passed...." > > That way, pinning updates would come in earlier even though the visit is > maybe only monthly. > Could possibly solve Trevor's use cases #2 and #3? > > Note: I would still not want the 30 day hard limit in the spec, because > I feel that this can give results that will be unexpected from a user > point of view... > > Best regards, Tobias >
Sorry for not chiming in sooner, but I don't think we'd consider a polling based solution as being viable for implementation. We've certainly discussed these in-house and had discussions with other browser vendors, and I don't think anyone is too enthused with the idea. I can certainly understand and appreciate Trevor's concerns - and I haven't really had a chance to sit down and give them the considered response they deserve - but I did want to provide at least some feedback before we got too far out there onto the 'background polling' bandwagon. Cheers, Ryan _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
