Hi Trevor <no hats>
The suggestion that web spiders also note pins is interesting, but it's not mentioned in the draft at all. So I believe that we have to take the draft at face value, that it is user agents that are supposed to note pins. BTW: assuming that relatively few sites have pins, it is also possible for the browser itself to load pages in the background to refresh the list of pins. Either way, we have to assume that the pin is noted by a user agent and is noted again only when the user clicks a link or types in the address again. I don't think we want to require anything else. I do agree that a spider or the browser itself can periodically check on pins. You go on to note three cases where limiting the max-age may be beneficial: 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). #2 and #3 make sense, but they only make sense as reasons to set max-age to a relatively short value. It may be good to incorporate this as advice to the administrator as to what to set max-age to. They are not a good reason, IMO, to set a hard limit in the protocol. So we're left with #1. And I would add to that the case where an attacker managed to get a valid-looking certificate for the domain (as in the diginotar case), and used the session to set a false pin with a long max-age. I agree that there's an issue here. I just think that it should be balanced against the needs of infrequently accessed domains. Yoav On May 18, 2013, at 8:40 PM, Trevor Perrin <tr...@trevp.net<mailto:tr...@trevp.net>> wrote: 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 <tobias.gond...@gondrom.org<mailto:tobias.gond...@gondrom.org>> 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 Email secured by Check Point _______________________________________________ websec mailing list websec@ietf.org<mailto:websec@ietf.org> https://www.ietf.org/mailman/listinfo/websec
_______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
