Re: [websec] #57: Re-add an upper limit to max-age

<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 <jbonneau@gmail.com> wrote:
>
>> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin <trevp@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.
>
> 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
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec