Hi Trevor, hi all, (again no hats)
actually regarding browser lookups of pin lists: I rather have the pins work unlimited and all the time even without pin lists. But your idea might in fact be a solution to enable the unlimited pin times. Instead of constantly distributing the list of pins, we could actually have browsers use whitelists of pins that have been "revoked" and where the browser is allowed to refresh. That could e.g. happen with a browser update. That way we can have a unlimited time pin (and pre-caching of pins) and solve the scenario of malicious domain blocking by previous owners. And hopefully that scenario will hardly happen at all (especially if there is a provision for solving it and the attempt is futile, the motivation for an attacker trying it might be close to zero). Best regards, Tobias On 03/06/13 07:29, Trevor Perrin wrote: > > Hi Yoav, all, > > We've talked a lot about the risks of long-lived pins. We should also > think more about the benefits. > > I'll argue that pin lifetimes past a certain point don't get you much. > Browser-based "key continuity" will hopefully be supplemented by > systems that scan pin assertions regularly from different points on > the Internet (like Perspectives, Convergence, Vantages, etc.). Such > systems would derive pins more reliably than individual browsers, and > could use several methods to distribute these pins. Since scanning of > sites can be done frequently, and distribution would also be fast, > long-lived pins aren't needed for this. > > The hard part of this isn't scanning, it's pin distribution. Here's > three ways that could be done: > > Links: Pins could be embedded in hyperlinks served over HTTPS. Since > much browsing consists of following links from the web's major > "introducers" (search engines, social networks, etc.), having these > sites embed pins would protect a lot of traffic. See the recent > "S-links" paper [1]. > > Lists: Modern browsers download lists of security info on a regular > basis, including lists of malware and phishing sites [2], > commonly-downloaded files [3], and revoked certs [4]. You could > imagine pin lists being downloaded, so that every browser has a > current list of pins for, say, 10,000 major sites. > > Lookups: Browsers are reluctant to do per-connection blocking lookups > (see OCSP, Convergence, and DNSSEC). But there might be more > efficient and less-problematic ways to combine pin and DNS lookups > (e.g. connections to DNS resolvers via VPNs, or some simpler form of > response authentication). Also, non-blocking pin lookups could be > used after-the-fact to detect attacks (if a MITM blocks the lookup for > an extended period, the browser would start complaining). > > > Anyways, 30-day pins seem adequate for any of these. Assuming sites > can be rescanned weekly, pins received through links, lists, or > lookups are likely to have 20+ days of validity left in them, which is > plenty of time for the browser to follow a link, or use a list without > its entries expiring. > > This is a complicated issue, and I don't expect this email to resolve > it. But I at least hope this lessens any perception that short-lived > pins would offer weak security. > > > Trevor > > [1] http://research.google.com/pubs/archive/41138.pdf > [2] https://developers.google.com/safe-browsing/ > [3] > http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequently-asked-questions-ie9 > [4] http://www.imperialviolet.org/2012/02/05/crlsets.html > > > > On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <[email protected] > <mailto:[email protected]>> wrote: > > Hi > > Just trying to get us close to consensus. Still no hats. There are > two arguments for limiting max-age: > > 1. With unlimited max-age, it's possible for the legitimate site > owner to by mistake damage their sites. You could pin the CA > certificate, and lock yourself in to that CA for all eternity. You > could pin a current and future EE public keys, and then when the > current public key expires, you might not use the future one > because you mistyped it (or your CA no longer accepts 1024-bit > keys). For whatever reason, a bad choice you make while trying out > HPKP either bricks your site or constrains your behavior for a while. > > 2. With unlimited max-age, a current owner of a domain name can > set a pin that a future owner cannot honor. So if Mr. diaper > consultant[1] ever decides to retire, he could set a long-lived > pin such that I would not be able to use the domain even if I buy > it. A variation on this is the case where an attacker like > ComodoHacker manages to MitM a popular site, and he sets a > long-lived pin that prevents users from accessing the site not > through the MitM. This means that browser support for HPKP could > serve to amplify attacks that are plenty bad enough as they are. > > Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a > pretty big gun with which users can shoot themselves in the foot. > A website that's important for its owner (whether it's social > networking, political action, or business) cannot afford to be > inaccessible for any length of time. A month is no less a disaster > than a year. As for constraining your behavior, this merits > deployment advice, not limiting the usefulness of the protocol for > other sites. > > #2 is more worrying. I think the previous owner issue would be > served even with a 1 year hard limit, and I don't think anyone > here is arguing that a 1-year limit is too short. But the attack > amplification is a real thing, and it works against sites that > haven't even implemented HPKP. Sites that deploy HPKP are > protected from a MitM such as ComodoHacker (or his "friends"). But > having HPKP in the browser (but not in the website) allows his > friends to lock out browsers by inserting a pin. So if browsers > implement this, it amplifies attacks against the general > population of SSL-protected web sites. I'm not sure whether in the > grand scheme of things this makes the Internet better or worse. > > Note, though, that this issue exists even if max-age is limited. > Bricking the site for a month (for some users in Iran) is a bad > enough outcome, only slightly mitigated by it being only for a month. > > I started out writing this message thinking it was going to have a > proposal that we could all reach consensus about. I'm not sure I > got there. I guess if this was a vote, I would vote for a > year-long max-max-age, but I'm not really as sure about this as I > was when I started writing this message. > > Yoav > > [1] http://www.yoavnir.com > _______________________________________________ > websec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/websec > > > > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
