<hat="individual"> I agree with Yoav's comment. Am not 100% sure on this, as I don't know the frequency of "self-bricking" due to the reasons described by Trevor, but feel that 30 days is too short for protection of rare use users. Don't forget, we have not solved the boot-strapping issue for HSTS and HKPK. So if the max-age is too low, we basically leave all infrequent users unprotected. (and I guess there are quite a number of important sites that people would only go to only once in a while but not for sure every 30 days).
If I would have to balance between "self-inflicted bricking" (due to mis-config, bad business deals, weak security, etc.) and user protection, my vote would go for user protection. So if we need a max-age, I would probably prefer a longer time, e.g. a max-age of 1 year. Best regards, Tobias On 23/03/13 10:13, Yoav Nir wrote: > On Mar 22, 2013, at 7:36 PM, Joseph Bonneau <[email protected]> wrote: > >> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin <[email protected]> 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. > > OTOH a particular public key might be replaced because of switching > certificate vendors, because auditors don't like that key length any more, or > because your certificate vendor has decided that ECC is the way to go. > Pinning something that has an expiry date for an unlimited time could be a > 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. If > either the draft or the UA sets an upper limit of 30 days, then HKPK won't > work for pub.ietf.org. This is a site that I only use from one week before an > IETF meeting to one week following it. In between there are a little over > three months where I don't use the site at all. So it would make sense for > the site operator to set a max-age of 4 months. That limit may be > inappropriate for web mail or social media, but even those might be accessed > from different UAs at different times. For example, I might use my home > computer for a social media site while I'm at home, but use a smart phone or > a laptop for the same site when I'm away from home. > > 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? > > Yoav > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
