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
