Re: CORS versus Uniform Messaging?
On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote: On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow art.bars...@nokia.com wrote: Ideally, the group would agree on a single model and this could be achieved by converging CORS + UM, abandoning one model in deference to the other, etc. Can we all rally behind a single model? I'm not sure that we want to. My impression is that both models have their advantages and risks. They basically implement two different security design philosophies, and I'm not confident that there is a winner, or that we can correctly pick one. I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. Hi Adam, the whole point of arguing is to settle controversies. That is how human knowledge advances. If after 40 years the ACL side has no defenses left for its position, ACL advocates should have the good grace to concede rather than cite the length of the argument as a reason not to resolve the argument. CORS seems easier in the simpler cases when no website acts as a deputy. UM seems less likely to cause confused deputy problems when a website acts as a deputy and receives urls from third parties (either by fetching them over the network, or by having third party code running in their domain using something like caja). I also agree with Jonas on these points. What might make the most sense is to let the marketplace decide which model is most useful. The most likely outcome (in my mind) is that they are optimized for different use cases and will each find their own niche. Of course it is left for the marketplace to decide. The W3C has no enforcement powers. We cannot arrest anyone for deviating from our standards. The purpose of standards committees is to influence these market decisions. We have seen the consequence of bad web standards in the marketplace -- they are generally implemented. We should not abdicate our responsibility to advise the market by producing good standards. -- Cheers, --MarkM
Re: CORS versus Uniform Messaging?
On Sat, Dec 12, 2009 at 11:14 PM, Maciej Stachowiak m...@apple.com wrote: I agree with Jonas and Adam as well. I think both models have their use cases. A few specific additional thoughts: - Something like UM seems pretty important, probably essential, for running guest code if you are relying on origin-based security at all to protect some of your resources. - UM may be sufficient for some patterns of cross-domain messaging, but is not necessarily the most convenient. - UM isn't strictly necessary for multi-party messaging interactions; CORS works fine too, as long as you don't rely on the Origin header as the sole security mechanism. - Building a shared-secret-based defense for the kinds of semi-public resources that Hixie has been discussing is likely to be overkill for the level of security actually required, to the point that the risk of making complexity-induced implementation mistakes may be greater than the risks you face from basing your security on origin checks. Please read again the CORS spec and the Uniform Messaging spec. Which one has the greater risk of complexity-induced implementation mistakes? As one example, the CORS preflight uses a duration to indicate how long the browser may cache an opt-out. But a duration from when? Server programmers will most naturally assume, from when the message was sent. After this period of time, they can consider the access granted by a preflight to be revoked, and to take action predicated on that revocation. More sophisticated server programmers will try to take clock skew and network latency into account -- despite the fact that CORS recommended server behavior never even mentions these hazards. However, as we know, an adversary in the network can delay https responses. How long can these responses be delayed? Frankly, I have no idea. Before CORS, I had no reason to worry about this issue. In any spec as complicated as CORS, there are likely to be many more such vulnerabilities. This one was found without much effort. - In many cases (not including guest code running in something like Caja, but including one-party form submission, simple two-party cross-domain communication, and complex multi-party communication) combining a secret token / shared secret based defense with an Origin check is likely to be more secure than either alone. I would even go so far as to make the following claims: (a) Given a reasonably secure shared-secret-based system, then other things being equal, adding Origin checks will not make your system less secure. (b) In many cases, adding Origin checks to such a system may make it more secure, in the sense that it is robust against more kinds of unexpected failures. I'd be happy to expand on the last point in a separate email if anyone cares to see some more detail and some examples. Please. I'm very interested. -- Cheers, --MarkM
Re: CORS versus Uniform Messaging?
On Dec 13, 2009, at 10:14 AM, Mark S. Miller wrote: On Sat, Dec 12, 2009 at 11:14 PM, Maciej Stachowiak m...@apple.com wrote: I agree with Jonas and Adam as well. I think both models have their use cases. A few specific additional thoughts: - Something like UM seems pretty important, probably essential, for running guest code if you are relying on origin-based security at all to protect some of your resources. - UM may be sufficient for some patterns of cross-domain messaging, but is not necessarily the most convenient. - UM isn't strictly necessary for multi-party messaging interactions; CORS works fine too, as long as you don't rely on the Origin header as the sole security mechanism. - Building a shared-secret-based defense for the kinds of semi- public resources that Hixie has been discussing is likely to be overkill for the level of security actually required, to the point that the risk of making complexity-induced implementation mistakes may be greater than the risks you face from basing your security on origin checks. Please read again the CORS spec and the Uniform Messaging spec. Which one has the greater risk of complexity-induced implementation mistakes? To clarify, I mean complexity in implementing a defense using the mechanism, as opposed to complexity involved in implementing the mechanism in the browser. As one example, the CORS preflight uses a duration to indicate how long the browser may cache an opt-out. But a duration from when? Server programmers will most naturally assume, from when the message was sent. After this period of time, they can consider the access granted by a preflight to be revoked, and to take action predicated on that revocation. More sophisticated server programmers will try to take clock skew and network latency into account -- despite the fact that CORS recommended server behavior never even mentions these hazards. However, as we know, an adversary in the network can delay https responses. How long can these responses be delayed? Frankly, I have no idea. Before CORS, I had no reason to worry about this issue. Good point. I can think of a couple of ways to handle this: 1) The spec could say that severs should not count on preflight information expiring at any particular time, except relative to the cache lifetime of subsequent responses. This is likely to be a sufficiently strong condition in most cases. I don't believe an attacker can selectively choose which https responses to delay. 2) Expiration for the preflight could be specified as an absolute time (in GMT) instead of as a delta, then clock skew may be a factor, but latency or artificial delay may not be. In any spec as complicated as CORS, there are likely to be many more such vulnerabilities. This one was found without much effort. Let's find them then. - In many cases (not including guest code running in something like Caja, but including one-party form submission, simple two-party cross-domain communication, and complex multi-party communication) combining a secret token / shared secret based defense with an Origin check is likely to be more secure than either alone. I would even go so far as to make the following claims: (a) Given a reasonably secure shared-secret-based system, then other things being equal, adding Origin checks will not make your system less secure. (b) In many cases, adding Origin checks to such a system may make it more secure, in the sense that it is robust against more kinds of unexpected failures. I'd be happy to expand on the last point in a separate email if anyone cares to see some more detail and some examples. Please. I'm very interested. All right. I'll need to make some diagrams and I'm pretty busy with end-of-year stuff, so I may not get a chance to send this until after the holidays. Regards, Maciej
Re: CORS versus Uniform Messaging?
On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller erig...@google.com wrote: On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote: I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. Hi Adam, the whole point of arguing is to settle controversies. That is how human knowledge advances. If after 40 years the ACL side has no defenses left for its position, ACL advocates should have the good grace to concede rather than cite the length of the argument as a reason not to resolve the argument. I seriously doubt we're going to advance the state of human knowledge by debating this topic on this mailing list. The scientific community is better equipped for that than the standards community. Adam
Re: CORS versus Uniform Messaging?
On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth w...@adambarth.com wrote: On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller erig...@google.com wrote: On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote: I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. Hi Adam, the whole point of arguing is to settle controversies. That is how human knowledge advances. If after 40 years the ACL side has no defenses left for its position, ACL advocates should have the good grace to concede rather than cite the length of the argument as a reason not to resolve the argument. I seriously doubt we're going to advance the state of human knowledge by debating this topic on this mailing list. The scientific community is better equipped for that than the standards community. AFAICT, the last words on this debate in the scientific literature are the Horton paper http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller.pdf and the prior refutations it cites: Because ocaps operate on an anonymous “bearer right” basis, they seem to make reactive control impossible. Indeed, although many historical criticisms of ocaps have since been refuted [11, 16, 10, 17], a remaining unrefuted criticism is that they cannot record who to blame for which action [6]. This lack has led some to forego the benefits of ocaps. The point of the Horton paper itself is to refute that last criticism. [11] Capability Myths Demolished http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf or http://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/ Referee rejection of Myths at http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html. Read carefully, especially Boebert's criticisms. [16] Verifying the EROS Confinement Mechanism http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6577 [10] Robust Composition http://erights.org/talks/thesis/. Notice in particular the counter-example to Boebert's famous claim in seven lines of simple code, in Figure 11.2. [17] Patterns of Safe Collaboration http://www.evoluware.eu/fsp_thesis.pdf, which does a formal analysis of (among other things) confused deputy, Boebert's claim, and my counter-example. [6] Traditional capability-based systems: An analysis of their ability to meet the trusted computer security evaluation criteria. http://www.webstart.com/jed/papers/P-1935/ If you know of any responses to these refutations in the scientific literature, please cite them. If you believe (as I do) that the lack of responses is due to ignorance and avoidance, then either 1) the scientific community has shown itself less well equipped to engage in this debate than those who are actively engaged in it -- such as us here on this list, 2) that the case against these alleged refutations are so obvious that they need not be stated, or 3) that the members of the scientific community that cares about these issues have found no flaw in these refutations -- in which case they legitimately should stand as the last word. In either of the first two cases, since you are a member both of the scientific community and of this standards committee, if you don't respond in the scientific literature, please don't cite merely the lack of response in the scientific literature in support of your points. -- Cheers, --MarkM
Re: CORS versus Uniform Messaging?
On Sun, Dec 13, 2009 at 1:29 PM, Mark S. Miller erig...@google.com wrote: On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth w...@adambarth.com wrote: On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller erig...@google.com wrote: On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote: I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. Hi Adam, the whole point of arguing is to settle controversies. That is how human knowledge advances. If after 40 years the ACL side has no defenses left for its position, ACL advocates should have the good grace to concede rather than cite the length of the argument as a reason not to resolve the argument. I seriously doubt we're going to advance the state of human knowledge by debating this topic on this mailing list. The scientific community is better equipped for that than the standards community. AFAICT, the last words on this debate in the scientific literature are the Horton paper http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller.pdf and the prior refutations it cites: Because ocaps operate on an anonymous “bearer right” basis, they seem to make reactive control impossible. Indeed, although many historical criticisms of ocaps have since been refuted [11, 16, 10, 17], a remaining unrefuted criticism is that they cannot record who to blame for which action [6]. This lack has led some to forego the benefits of ocaps. The point of the Horton paper itself is to refute that last criticism. [11] Capability Myths Demolished http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf or http://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/ Copy paste error, sorry. That second link was an additional link for Horton, not for Myths. Referee rejection of Myths at http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html. Read carefully, especially Boebert's criticisms. [16] Verifying the EROS Confinement Mechanism http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6577 [10] Robust Composition http://erights.org/talks/thesis/. Notice in particular the counter-example to Boebert's famous claim in seven lines of simple code, in Figure 11.2. [17] Patterns of Safe Collaboration http://www.evoluware.eu/fsp_thesis.pdf, which does a formal analysis of (among other things) confused deputy, Boebert's claim, and my counter-example. [6] Traditional capability-based systems: An analysis of their ability to meet the trusted computer security evaluation criteria. http://www.webstart.com/jed/papers/P-1935/ If you know of any responses to these refutations in the scientific literature, please cite them. If you believe (as I do) that the lack of responses is due to ignorance and avoidance, then either 1) the scientific community has shown itself less well equipped to engage in this debate than those who are actively engaged in it -- such as us here on this list, 2) that the case against these alleged refutations are so obvious that they need not be stated, or 3) that the members of the scientific community that cares about these issues have found no flaw in these refutations -- in which case they legitimately should stand as the last word. In either of the first two cases, since you are a member both of the scientific community and of this standards committee, if you don't respond in the scientific literature, please don't cite merely the lack of response in the scientific literature in support of your points. -- Cheers, --MarkM -- Cheers, --MarkM
Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
I enter this subthread with trepidation, because I do not think the Working Group is in a position to engage in a literature review on an active research topic. However, a few comments below: On Dec 13, 2009, at 1:29 PM, Mark S. Miller wrote: On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth w...@adambarth.com wrote: On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller erig...@google.com wrote: On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote: I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. Hi Adam, the whole point of arguing is to settle controversies. That is how human knowledge advances. If after 40 years the ACL side has no defenses left for its position, ACL advocates should have the good grace to concede rather than cite the length of the argument as a reason not to resolve the argument. I seriously doubt we're going to advance the state of human knowledge by debating this topic on this mailing list. The scientific community is better equipped for that than the standards community. AFAICT, the last words on this debate in the scientific literature are the Horton paper http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller.pdf and the prior refutations it cites: Because ocaps operate on an anonymous “bearer right” basis, they seem to make reactive control impossible. Indeed, although many historical criticisms of ocaps have since been refuted [11, 16, 10, 17], a remaining unrefuted criticism is that they cannot record who to blame for which action [6]. This lack has led some to forego the benefits of ocaps. The point of the Horton paper itself is to refute that last criticism. That paper seems to respond to a criticism of object-capability systems. Specifically, it shows a protocol that apparently lets you associate communication with an identity in an object capability system to allow logging and reactively restricting access. At least I'm pretty sure it does, it took me several readings to properly undertand it. This paper does not appear to give an argument that capability models are in general superior to other models. [11] Capability Myths Demolished http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf or http://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/ Those two don't seem to link to the same paper. Referee rejection of Myths at http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html . Read carefully, especially Boebert's criticisms. I'm not sure what we are supposed to conclude from the rejection comments (or from a rejected paper in general). [16] Verifying the EROS Confinement Mechanism http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6577 The point being made her seems too technical to relate to the current discussion (at least to my non-expert understanding). [10] Robust Composition http://erights.org/talks/thesis/. Notice in particular the counter-example to Boebert's famous claim in seven lines of simple code, in Figure 11.2. [17] Patterns of Safe Collaboration http://www.evoluware.eu/fsp_thesis.pdf , which does a formal analysis of (among other things) confused deputy, Boebert's claim, and my counter-example. [6] Traditional capability-based systems: An analysis of their ability to meet the trusted computer security evaluation criteria. http://www.webstart.com/jed/papers/P-1935/ There seems to be a whole lot of material on whether capability-based systems can enforce the *-property. It's not obvious to me how this is relevant to the discussion. If my understanding of the *-property is correct, it's not a property that we are trying to enforce in the context of Web security. But to be fair, I did not know what the *- property was until just a few minutes ago, so my opinion cannot be considered very well informed. If you know of any responses to these refutations in the scientific literature, please cite them. If you believe (as I do) that the lack of responses is due to ignorance and avoidance, then either 1) the scientific community has shown itself less well equipped to engage in this debate than those who are actively engaged in it -- such as us here on this list, 2) that the case against these alleged refutations are so obvious that they need not be stated, or 3) that the members of the scientific community that cares about these issues have found no flaw in these refutations -- in which case they legitimately should stand as the last word. The literature you cited seems to mostly be about whether capability systems have various technical flaws, and whether they can be made to do various things that ACL-based systems can do. This does not seem to me to show that the science is settled on how to design security systems. I'm also not sure that this Working Group is an appropriate
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak m...@apple.com wrote: I enter this subthread with trepidation, because I do not think the Working Group is in a position to engage in a literature review on an active research topic. However, a few comments below: I am not the one who brought up the controversy dating from the '70s as relevant to this discussion. I am merely clarifying how one should interpret the history of that controversy. On Dec 13, 2009, at 1:29 PM, Mark S. Miller wrote: On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth w...@adambarth.com wrote: On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller erig...@google.com wrote: On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote: I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. Hi Adam, the whole point of arguing is to settle controversies. That is how human knowledge advances. If after 40 years the ACL side has no defenses left for its position, ACL advocates should have the good grace to concede rather than cite the length of the argument as a reason not to resolve the argument. I seriously doubt we're going to advance the state of human knowledge by debating this topic on this mailing list. The scientific community is better equipped for that than the standards community. AFAICT, the last words on this debate in the scientific literature are the Horton paper http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller.pdf and the prior refutations it cites: Because ocaps operate on an anonymous “bearer right” basis, they seem to make reactive control impossible. Indeed, although many historical criticisms of ocaps have since been refuted [11, 16, 10, 17], a remaining unrefuted criticism is that they cannot record who to blame for which action [6]. This lack has led some to forego the benefits of ocaps. The point of the Horton paper itself is to refute that last criticism. That paper seems to respond to a criticism of object-capability systems. Specifically, it shows a protocol that apparently lets you associate communication with an identity in an object capability system to allow logging and reactively restricting access. At least I'm pretty sure it does, it took me several readings to properly undertand it. This paper does not appear to give an argument that capability models are in general superior to other models. Agreed. Since no one any more challenges the assertion that ocaps are superior to ACLs in some ways, the remaining question is whether ACLs are superior to ocaps in other ways. If they are not, then ocaps and simply strictly superior to ACLs. The references cited refute prior claims about weaknesses of ocaps compared to ACLs. [11] Capability Myths Demolished http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf or http://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/ Those two don't seem to link to the same paper. Yes, my mistake. The second link is another link to Horton, not to Myths. Referee rejection of Myths at http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html. Read carefully, especially Boebert's criticisms. I'm not sure what we are supposed to conclude from the rejection comments (or from a rejected paper in general). [16] Verifying the EROS Confinement Mechanism http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6577 The point being made her seems too technical to relate to the current discussion (at least to my non-expert understanding). Adam is an expert. I am challenging him wrt the status of the debate in the scientific literature and what we should conclude from it, since he raised the topic. [10] Robust Composition http://erights.org/talks/thesis/. Notice in particular the counter-example to Boebert's famous claim in seven lines of simple code, in Figure 11.2. [17] Patterns of Safe Collaboration http://www.evoluware.eu/fsp_thesis.pdf, which does a formal analysis of (among other things) confused deputy, Boebert's claim, and my counter-example. [6] Traditional capability-based systems: An analysis of their ability to meet the trusted computer security evaluation criteria. http://www.webstart.com/jed/papers/P-1935/ There seems to be a whole lot of material on whether capability-based systems can enforce the *-property. It's not obvious to me how this is relevant to the discussion. If my understanding of the *-property is correct, it's not a property that we are trying to enforce in the context of Web security. But to be fair, I did not know what the *-property was until just a few minutes ago, so my opinion cannot be considered very well informed. I actually think the *-properties are almost completely unimportant, and hardly ever relate to any practical issue. However, Boebert's impossibility claim was then repeatedly cited, including by
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Dec 13, 2009, at 3:47 PM, Mark S. Miller wrote: On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak m...@apple.com wrote: The literature you cited seems to mostly be about whether capability systems have various technical flaws, and whether they can be made to do various things that ACL-based systems can do. This does not seem to me to show that the science is settled on how to design security systems. If there are undisputed weaknesses of ACLs compared to capabilities, and undisputed refutations of all claimed weaknesses capabilities compared ACLs, then what more is needed for the science to be settled? Even if that is true with respect to formal security properties (and I honestly don't know), it doesn't necessarily show that ACL-based systems are always dangerously unsafe, or that the formal differences actually matter in practice in a particular case, enough to outweigh any pragmatic considerations in the other direction. I'm also not sure that this Working Group is an appropriate venue to determine the answer to that question in a general way. I don't think most of us have the skillset to review the literature. Beyond that, our goal in the Working Group is to do practical security analysis of concrete protocols, and if there are flaws, to address them. If there are theoretical results that have direct bearing on Working Group deliverables, then the best way to provide that information would be to explain how they apply in that specific context. Fine with me. That's what we were doing before Adam raised the history of this controversy as an argument that we should stop. One important point to consider is that we are not deploying into a vacuum. The Web already pervasively makes use of tokens that are passively passed around to identify the agent (I feel a little weird calling these ACLs given the specific uses). In particular, the notion of origin is used already to control client-side scripting access to the DOM; and cookies are used pervasively for persistent login. I don't see a clear plan on the table for removing these passive identifiers. Removing same-origin policy for scripting would require either majorly redesigning scripting APIs or would lead to massive security holes in existing sites. As for cookies, it does not seem anyone has a practical replacement that allows a user to persistently stay logged into a site. In fact, many proposed mechanisms for cross- site communication ultimately depend at some point on cookies, including you and Tyler's proposed UM-based protocol for cross-site communication without prior arrangement. Even if a pure capability-based system is better than a pure ACL-based system (and I really have no way to evaluate, except to note that a large number of security architectures in widespread production use seem to be on some level ACL-based), it's not clear to me that solely pushing capabilities is the best way to improve the already existing Web. There seem to be two schools of thought that to some extent inform the thinking of participants in this discussion: 1) Try to encourage capability-based mechanisms by not providing anything that lets you extend the use of origins and cookies. 2) Try to build on the model that already exists and that we are likely stuck with, and provide practical ways to mitigate its risks. I don't see how we are going to settle the disagreement by further mailing list debate, because it seems to me that much of it is at the level of design philosophy, not provable security properties. Regards, Maciej
