Hi Chris, (also no hats)
thanks for the clarification. If either "no-limit" and "hard-limit" would both be ok for you (and others), then I would be strongly in favor of "no-limit". (note: I recognise that the side effect of "no-limit" is that domain squatters can brick a site for a longer time after the domain had been handed over. But actually considering that we plan to do some pre-caching deployment in browsers anyway, the browsers might also be the solution for this problem. Like doing a "clear pin cache for domain xyz" in case of really malicious pin bricking.) Best regards, Tobias On 29/05/13 06:16, Yoav Nir wrote: > Hi Chris > > (again, no hats) > > On May 29, 2013, at 3:23 AM, Chris Palmer <[email protected]> wrote: > >>> 1. user choice is a bad idea when it comes to security. >>> Just remember the many SSL cert "click to proceed anyway pop-up >>> windows/issues..." >>> In most cases the user is not qualified to fully understand the >>> consequences of his choice. >> Yes. But, in this case, the choice is between status-quo HTTPS and >> extra-happy pinned HTTPS. That's a very different proposition than >> clearly-broken HTTPS vs. status-quo HTTPS, for example. Also, failing >> closed would probably be a deal-breaker for deployment, at least at >> this time. Finally, for sites that people use regularly — Facebook, >> Gmail, Twitter — users will still get good protection. Arguably, these >> are the sites that are mature and most likely to be able to deploy >> pinning; > People having multiple devices kind of screws this up. People may use the > same site every day, but they might not use the same site from the same > device every day. So if someone uses mostly a phone to access facebook, they > may go a whole month without accessing it from their desktop or laptop. > Limiting pins to 30 days means your less-used devices, which may be on a > totally different network than your phone, are not protected. > >> it's the banks and other occasionally-visited sites that >> should probably stick to Report-Only mode anyway, because they are >> less mature *as web technology companies*. Thus I would argue that, at >> least for now, the sites that would most likely fail open due to limit >> son the max-max-age are sites that should fail open anyway, for other >> reasons. > Disagree on that. Banks and other financial institutions are not web > technology companies, but they deal with real money and they have real money > with which to buy such expertise. It's no coincidence that banks were very > early adopters of anti-XSS and anti-CSRF measures, and it's no coincidence > that one of this group's biggest contributors works for Paypal, which is no > less a financial institution than any bank or credit card companies. If we > can't help protect the transactions that involve money, what's the point? > >> However, that's a bit of a tangent. As it is, many sites that really >> need pinning protection can get it under this I-D, and others can gain >> nice information from Report-Only mode, and others do no worse than >> the status quo. >> >>> 2. as you seem to advocate a hard limit of 30 days. >> Not exactly; I find Trevor's call for simple clarity compelling, but I >> also like a browser-determined limit past which we fail open (for the >> reasons described above). I could happily go either way, which doesn't >> really help, I realize. :) Ryan and I can just make a call one way or >> the other and write it up, is that OK? > By "fail open", do you mean fail with a warning to the user, or just silently > ignore the pin? If it's the latter, than letting each implementation choose > a max-max-age does not address Trevor's concerns. If some site sent a pin > with max-age of 10 years, they can fix the pin that they send, but they have > to assume that for the next 10 years some browsers out there have recorded > the way-too-long pin. Maybe this means that they can't switch root CAs. If > you set max-max-age in the RFC to 30 days, they can know that all those > browsers will have lost the pin after a month. If you let every UA choose > their own max-max-age, they have to assume the maximum, and hope that they > even know the maximum. They might think that taking the maximum among Chrome, > Firefox, IE, Safari and Opera gets them there. They might not have ever heard > of a browser called OmniWeb for Mac (just using an obscure one as an > example). But if OmniWeb sets no limits on pins and they change CAs after 1 > year, they are going to get a whole bunch of support calls from people using > a browser they've never heard of. > > So I think we should either set no limits, or set hard limits. > >>> Could you think of >>> browsers refreshing their PINs before expiry automatically? (i.e. >>> without the user actually visiting the site?) >>> And question to all: would this open Pandora's box in terms of privacy >>> etc. as we would leak the list of pinned sites to servers in the middle? >> Right, exactly. I don't want to have browsers unilaterally leaking >> information by proactively pre-scanning particular sites. However, an >> oft-updated master list, like Chrome's CRLSets but for pins culled by >> crawling sites and looking for pin updates, might be workable. But I'd >> consider that a nice-to-have that is out of the I-D's immediate scope. > I agree that we can't mandate that each UA has access to the results of some > web crawler looking for pins. > > Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
