On Wed, May 22, 2013 at 2:02 PM, Tobias Gondrom <[email protected]>wrote:
> > And maybe a question to go a step further: > Would you agree that if we would do a 30-day hard limit as you propose, > this would basically mean that all less frequent banking/paypal/... users > MUST (or a very strong SHOULD) use such a web crawler to make sure that > their pin has not expired before they come back? > Pins created by the UA itself won't protect initial connections, or provide security when expired. These are inherent limits of UA-derived pins. So I don't think a spec-limit makes these problems dramatically worse, or requires new mandates for UAs. You could, however, note the deficiences of UA-derived pins in the Security Considerations, and say something something like: "Clients are advised to make use of 3rd-party trust infrastructure so that pins can be aggregated and shared. This will require additional protocols outside the scope of this document." > This would be a big problem in my eyes, as IMHO this assumption can not be > guaranteed nor expected to be rolled out consistently. > > > >> 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). > > > Hm, in my view case #2 and #3 are about your own pinning time frames and > should be ok with recommendations, but would not require hard limits in the > draft. And in fact as we have multiple pins in the header we have a > migration path from A to B during that transition. > Being able to assert multiple pins in the header doesn't avoid lock-in problems. In a lock-in scenario there could be extant pins in clients to the set of keys (X,Y,Z). Thus you *cannot* safely stop using one of keys (X,Y,Z) until those pins expire. Advertising new pins doesn't fix the problem, cause you can't be guaranteed of reaching all existing clients. > Reading your cases, it feels to me #1 the malicious domain name transfer > is the strongest case. > Is that in your opinion as well? > Not sure. Trevor
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
