On Fri, Mar 22, 2013 at 7:13 PM, Yoav Nir <y...@checkpoint.com> wrote: > > On Mar 22, 2013, at 7:36 PM, Joseph Bonneau <jbonn...@gmail.com> wrote: > >> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin <tr...@trevp.net> wrote: >>> With a spec maximum (say 30 days), then you have a clear reference >>> point to plan around. >> >> Agreed. >> >> I have some stats I've been looking at from Google's web crawls about >> HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a >> max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1 >> day, and a smattering of other choices (with a few large hosts like >> Twitter setting very long-lived max-age). > > As Ekr said in the meeting, there is a big difference here between HSTS and > HPKP. It doesn't matter if Paypal or some bank advertises HSTS for a million > years. It's not likely that someone who has declared a policy for always > using secure transport will suddenly switch to non-secure transport. They > might stop advertising HSTS, but they're not likely to stop insisting on TLS > use.
Hi Yoav, Agreed that the issues around "pin lifetimes" are very different for HSTS and key pinning. If HSTS get mistakenly or maliciously set for your domain, it's no big deal. You just deploy SSL. If your domain gets pinned to keys you don't control, it's a big problem. > Something to consider is that if the max-age time is shorter than the time > between accesses to the site, the security of this mechanism is lost. I agree we'd like more security than a 30-day browser-side "key continuity" window. This is perhaps controversial, but I'd hope we could get that additional security *without* cranking up pin lifetimes, by considering ways to use pinning beyond just browser-side key continuity. For example: * Web crawlers could build pin lists for all sites they observe. * Browsers could periodically download a subset of these pin lists (for the most popular sites, or for communities of sites relevant to them). * "Trusted introducers" such as search engines could embed pins from a pin list into "secure links" that they serve. * Browsers could do online lookups to a pin list (whether blocking a la Convergence or after-the-fact a la Certificate Transparency). These ideas are all enabled or enhanced by key pinning, but they don't require long pin lifetimes. They just require pin lifetimes large enough that recrawling / redownloading pin lists / clearing caches etc. doesn't have to be done too frequently. > I understand Trevor's issue. Does it make a difference to a site operator > whether the site is partially bricked by bad pins for 30 days or 365 days? Consider cybersquatting or a domain name dispute, where someone loses control of a domain to its new (rightful) owner. The loser could set key pins before the domain is transferred, either for spite or to ransom the keys to the new owner. If the new owner has to wait 30 days before the domain is usable, that's a bummer but seems on the edge of tolerable. A year would be a long time. More generally, I think the important dictums here are: * First, do no harm * Second, don't scare users away! The biggest risk is not that the protection window will be too short, it's that we'll screw up the Internet, and the mechanism will be (or will be perceived as) too dangerous to use. So, I think it's best to push tradeoffs like this in the direction of safe, fail-open behavior, instead of trying to squeeze out every possible bit of "security". Trevor _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
