On Wed, May 22, 2013 at 7:43 PM, Daniel Veditz <[email protected]> wrote:
> On 5/22/2013 3:29 PM, Trevor Perrin wrote: > >> The draft discusses "Preloaded Pin Lists", which are presumably conveyed >> to the UA from some 3rd party (eg browser vendor). It seems reasonable >> for such lists to be created or kept fresh by scanning web sites. I >> believe Mozilla is taking this approach to HSTS [1]. >> > > Note that Mozilla currently requires sites to specify an HSTS pinning time > of at least 18 WEEKS to be included in the pre-load list. There was concern > that sites with shorter pins could have stopped using HSTS by time that > version of the browser shipped. I personally think that's a little strict, > but even if we relaxed the requirement to the length of a Beta cycle that's > still a longer period of time (6 weeks) than the maximum 30 days you're > suggesting. > Hi Daniel, That seems like a downside of compiling preloads into browser binaries, as done by Chrome and Firefox. But it looks like Google and Mozilla have both considered having the browser query a service to update a local list. That seems like a better approach, since it would eliminate this problem of shipping a build with pin information that is several weeks stale, and can only be updated with a new browser binary. https://code.google.com/p/chromium/issues/detail?id=175207 "As both the pinning list grows, and our desire to have a consistent pinning list across all versions of Chromium, we should look to move the static pin database into a module that may be updated independently of the main Chromium binary." https://wiki.mozilla.org/Privacy/Features/HSTS_Preload_List "There are two ways to accomplish this: 1. Hard-code the list in each shipping version of Firefox 2. Stand up a service (like blocklist ping) that serves the list upon request." Trevor
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
