Hi Tobias, all, I think Tobias gives a fair summary of the arguments against a 30-day spec limit. Let me summarize the opposing arguments:
On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom <[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. > And regarding some of the concerns of pro-longed malicious bricking by > an attacker after an attack has been resolved: > Two scenarios: > 1. I believe if we have a time limit of more than 1 month we need a > different mechanism (e.g. user actively flushing the key cache) anyway. > 2. in the case of high frequency sites (like you mentioned Facebook), > imagine even a 1 month brick time would already be considered > unacceptable too long by most users (in fact probably everything above a > few hours would be considered too long) and trigger user action to flush > the cache. > Agreed that a 30-day limit is not, by itself, sufficient mitigation against "malicious bricking by an attacker after an attack". I suspect pinning will need several additional mechanisms to prevent, limit, and recover from such attacks. "Pin activation" is one mechanism I think is particularly helpful, for this case. A 30-day spec limit is more important for other reasons: 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, etc.) 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which you lose trust in and suspect might be participating in MITM attacks; you are not bricked, but you are unable to change to a different CA and assert new CA pins until the old pins expire. 3) Pruning the amount of pin history you must keep your site consistent with (Do you remember what pins you or the previous domain owner asserted 6 month ago? 6 years ago? ever? They might still be out there, waiting to trip you up). In each of these cases, the site has a decision to make: 1) When can the site start using its new domain name? 2) When can the site change pinned keys? 3) What certificate chains are consistent with extant pins? Having a mandated 30-day limit makes these questions easier: 1) The site can always use a new domain name 30 days after acquiring it. 2) The site can always change pinned keys 30 days after last asserting the pin. 3) The site only has to consider pin assertions from the last 30 days. If browsers can take "creative" approaches to pin limits, per Tom Ritter [1], it's harder for sites to make these decisions. Sites would need to know what algorithms / parameters every browser is using and has used in the past. And if some browsers made bad decisions and store excessively long pins, the site will have to decide whether it's OK to make changes even if some users will have problems. Anyways, I think making things safe and simple for site operators is more important than browser creativity, or trying to maximize pinning's security benefits. That's why I still prefer a spec-mandated limit. And I think 30 days strikes a good balance between security benefits and safety, and is easy to remember and explain. Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01597.html
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
