Indeed, there has been a lot of back and forth on the topics of XDR and XHR2+AC over the last couple of weeks. This message is not attempting to set forth in detail all the objections we have had; Sunava will deliver that in a concise form. From the comments in various responses in this topic, it is clear that expectations are extremely high for the level of detail in those objections; that takes much time to prepare, and involves a number of people here across multiple teams. Some of these concerns are direct and technical, and might be fixed in the XHR2+AC draft; however, some of our most important concerns pertain to the approach of enabling cross-domain.
We are interested in participating in standardizing cross-domain access. We believe quite strongly that cross-domain access is one of the next enabling needs of the web platform, and we are most interested in enabling that in an interoperable way. However, we feel the design of grafting cross-domain access on to the already-existing XHR system is dangerous, and the current design is being arrived at by the method of discussing what developers want to do, then trying to make it safe, rather than starting with what is secure by principle and incrementally adding functionality. Experience has taught us it is much easier to ship a system that is secure by design and add functionality than try to secure a implementation after it ships by rolling back features. For example, today the current XHR draft proposes to block a list of headers that are unsafe only in a cross-domain context; however, this is difficult to deploy since XHR has already shipped, and challenging to imagine that there are no other headers in use by servers anywhere around the world that might not be good to access. There are fundamental cross domain security principles that we firmly believe need to be guaranteed by a cross domain solution; otherwise, our experience leads us to believe there will be exploits found over time. Cross-domain access in Flash has had a trail of bugs for these reasons [1]. Sunava will detail these security principles; I believe the XHR2+AC approach can currently be demonstrated to violate these. Even the AC draft itself has a list of security concerns and vague requirements as observed and discussed in the group [2]. Even if current vulnerabilities like exposure to Time of Check, Time of Use, DNS Rebinding attacks, and URL path canonicalization issues can be patched (rather than ignored), we are concerned that this approach to cross-domain access for the browser platform is not based first on security principles. It is extremely difficult to add security in as a feature after the design is done without creating cracks in that security. It is also quite difficult to add security on to an already-deployed API without creating large-scale incompatibilities with deployed uses. For example, is there a blocklist of headers? If so, how will this be maintained as the list of discovered headers grows? Will patching existing implementations in place through an automatic updating mechanism be sufficient to keep customers secure? In our opinion, one of the fundamental problems with the XHR2+AC proposal is that it blithely reuses an already-existing API for same-domain communication, and then attempts to patch the cracks that appear when it is used to perform cross-domain transfers. We want to be extremely clear that XDR is most definitely NOT, in our opinion, a “slightly different API that solves nearly the same problem” – neither is it “different for no extra benefit.” [3] Nor is it an “incompatible proposal,” [4] since it’s not intended to be merged with XHR or Access Control; it can happily coexist. XDR is not intended to be a competitor to XHR2+AC; it is different by design, and is focused on a much smaller set of cross-domain access needs. We believe it a principled and focused design. It is not, of course, the only principled, focused, or secure design that can be described. As for the XHR2+AC draft itself, I don't believe we intended anything we ever said to equate to “XHR2+AC is good;" I challenge the assertion of “Microsoft reviews W3C spec as good” [5] as an accurate generalization of what has been said [6]. This message did not claim to reflect a deep technical analysis of its contents of the Access Control draft, but let’s lay aside that concern; it is far more germane that there was no indication that we saw at the time that this access control mechanism would be simply directly applied to the XMLHttpRequest object. Even according to the designer of Access Control, the feature was designed for non browser applications, and the idea of enabling AC for the browser platform by applying Access Control to XHR “came as an afterthought.” [7]. As the AC draft has changed over time, and as it was applied to XHR, Microsoft has had increasing concerns over the security of the design of this proposal. These concerns come from painfully learned lessons about browser security, as we have seen many examples of how violating some basic security principles has led to vulnerabilities in the past. We’ve given the feedback that we believe this approach to enabling cross-domain is inherently insecure, but unfortunately the working group has not been receptive to these lessons we have learned from our experience. For example, one response was: “I'm also not sure how you could be surprised by the WGs vote not to replace years worth of work with a completely different and incompatible proposal. Especially when any security concerns could have been addressed by tweaks to the existing specification.” [8] In my opinion, this response is flawed on multiple levels; first, because we had never recommended throwing away all work on XHR2+AC and replacing it with XDR; we’ve suggested that XDR is a focused subset of cross-domain functionality that we believe is securable today. Certainly, XHR2+AC attempts to enable a lot more functionality; that would assure its place in the future. Secondly, I would think that issues of security in design would make it obvious that more work is necessary; just because something has been around for a year doesn’t mean it’s right, or that it is the best way of doing something. Finally, we disagree that the security concerns about XHR2+AC can be addressed by mere tweaks to the technical details. For example, I pointed out that the flow of this design is inherently open to DNS rebinding attacks [9], as well as other issues we’ve pointed out. I believe we have several times laid out some of our concerns with the current XHR2+AC method of doing cross-domain; it continues to be claimed that “nobody has responded to the requests for a description of these problems” [10]. I don’t believe that’s appropriate; I think whenever we do describe where we see design flaws and potential exploit area (e.g. [11]), there is a flurry of discussion that results in claims that it’s really not so bad, the exploits can happen in other situations anyway so don’t worry about it; or that such power is needed, and any cross-domain access design that doesn’t enable everything is flawed. The responses I’ve seen to the issues we have shared on this list have typically been dismissive that there is a problem – or presumptive that the problem can simply be spackled over. When we do go down detailed discussions, the threads seem to disappear (e.g. [12]). Alternately, the threads seem to devolve into acrimony, e.g. the back-and-forth over content-typing (where we are told “Stating this doesn’t make it true”). [13] In short, the discussion has devolved into unsupported sniping [14], including claims that XDR is less secure, that it is “arbitrary,” and that XHR2+AC is technologically superior without any objective measure of such or definition of metrics. At any rate, focusing on individual technical issues misses the point; spackling security over existing designs to extend them in ways they were not intended is very complex to get right. We have been calling for simplicity in the underlying design, rather than trying to graft secure cross-domain on to the already-existing APIs; hard experience has led us to be cautious and conservative. As Jon Ferraiolo of the OpenAjax Alliance said, “security trumps all others [concerns];” it was gratifying to have his support on the principle of being conservative, and see that some others do recognize that adding incremental complexity to already-existing APIs adds up to “a small beast”. [15] To address these concerns, we built a simpler, more focused API to enable some set of cross-domain access we felt could be secured, in the most focused way possible. Unlike Access Control, XDR is modeled off the defacto security policy defined by HTML 4.0 – that is, the prohibition against HTTP methods other than GET and POST and limitations of HTTP headers are in the HTML 4.0 specification and widely used as Tyler Close from HP pointed out to the Web API mailing list. [16] Indeed, the Open Ajax Alliance claims that XDR promises to be simpler and more secure [17]. I do want to be clear, since there was some confusion based on a conversation between Charles and Michael Champion – we will be shipping our XDR implementation in IE8 (modified by any feedback we might get before we must lock down for release). As we’ve said, we'd welcome feedback on XDR [18], and if it is timely enough, it could be incorporated into our IE8 product. We would of course be happy if this minimal, secure subset were to be accepted as a submission by the WG, turned into a deliverable and improved by an open standards process – and if that were the case, I believe it would be our responsibility to modify our implementation to comply with the (eventual) standard. However, we recognize that the Web API WG has voted informally to not pursue the XDR submission; in our view that makes it more imperative that the WebAPI’s design be made really secure if it is to be a W3C Recommendation and the only way to interoperably enable access across domains; but this does not change the customer need for us to ship a secure subset of cross-domain capabilities in this release of IE. We will of course continue to participate in the Web API WG’s work on cross-domain access, and I hope that work can be made secure to our satisfaction (and therefore implementable in IE); but we simply cannot implement APIs that we believe expose customers to security exploits. We desire interoperability; we cannot enable that at the expense of security. -Chris [1] http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html [2] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0150.html [3] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0205.html [4] http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html [5] http://www.w3.org/2008/Talks/0421-ac-tbl/#(4) [6] http://lists.w3.org/Archives/Public/public-appformats/2007May/0029.html [7] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0154.html [8] http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html [9] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html [10] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0209.html [11] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html [12] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/050.html [13] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html [14] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0206.html [15] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0099.html [16] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0095.html [17] http://www.regdeveloper.co.uk/2008/03/28/openajax_alliance_internet_explorer_eight/ [18] http://lists.w3.org/Archives/Public/public-appformats/2008Mar/0017.html -----Original Message----- From: Charles McCathieNevile [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 7:30 AM To: Sunava Dutta Cc: Chris Wilson; Web API WG (public); [EMAIL PROTECTED]; Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey Subject: Re: IE Team's Proposal for Cross Site Requests There has been rather more to-ing and fro-ing than actual work, it seems. I am happy to schedule a teleconference, and to ensure that Anne is available (as editor of XHR I think he is a critical resource). But we need to establish an agenda. (I am also trying to organise a face to face meeting to ensure that we can work as rapidly as possible - people are implementing stuff now and I would hate things to slow down to the point where people effectively opt out of the standards process and just ship something different). Before trying to schedule a teleconference, we need an agenda. As Maciej and others have noted, these are potentially complicated issues and we need to have reading time before the meeting in order to avoid wasting valuable teleconference time. The results of the survey on simply sopting IE's approach were pretty conclusive. The reasons given seem pretty clear, such as a desire not to fork requests in the first place, a belief that moving security risk from the implementation of requests to each specific use of a request actually increases the risk for end-users. Microsoft apparently feels that there are reasons to implement something other than the standard approach being developed, since they did so and I presume it was not from bloody-mindedness or ignorance. In order to usefully address these issues we need to understand them. Which means we are waiting on Microsoft to provide written feedback. Given the months that elapsed between the last time feedback was promised and when it was delivereed, I am reluctant to schedule teleconferences before such feedback is provided, at least sufficient to justify holding a teleconference. cheers Chaals (as chair, webapi woring group) On Sat, 03 May 2008 00:51:27 +0100, Sunava Dutta <[EMAIL PROTECTED]> wrote: > Maciej wrote: > " I would also prefer to see a clear statement of Microsoft's position > in written form ahead of the telecon. By their nature, these are > issues that need careful analysis, and cannot be evaluated fully in > the context of a teleconference." > > I think the request will help discussion. Yes, we will be making our > position and points that need further deliberation available in a > written form prior to the teleconference. > > -----Original Message----- > From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 29, 2008 5:01 PM > To: Ian Hickson > Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public); > [EMAIL PROTECTED]; Eric Lawrence; Zhenbin Xu; Gideon Cohn; > Sharath Udupa; Doug Stamper; Marc Silbey > Subject: Re: IE Team's Proposal for Cross Site Requests > > > On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote: > >> >> On Tue, 29 Apr 2008, Chris Wilson wrote: >>> >>> Given the multitude of issues raised, and the obvious back-and-forth >>> that denotes many differing opinions, I'd suggest having a telecom to >>> discuss these questions, and make sure that Sunava, Eric and myself >>> can >>> attend. >> >> I'm with Anne on this. Please reply to the e-mails before convening a >> telecon. It is very difficult to carefully consider feedback in the >> context of a telecon. >> >> The problem isn't "back-and-forth" denoting "many differing >> opinions", the >> problem is that we don't know what Microsoft's opinion _is_. >> >> Telecons are by their nature much less open, and minutes are almost >> uniformly so poor that it is hard to impossible to get precise >> technical >> details out of telecons. A telecon would not be appropriate at this >> point. > > I would also prefer to see a clear statement of Microsoft's position > in written form ahead of the telecon. By their nature, these are > issues that need careful analysis, and cannot be evaluated fully in > the context of a teleconference. > > Regards, > Maciej > > > -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
