RE: IE Team's Proposal for Cross Site Requests

Hi Chris,
Just to be clear, OpenAjax Alliance as an organization has not established
a formal position on the debate of XHR2+AC, XDR or other similar
cross-domain request proposals. The alliance isn't taking sides one way or
the other, although we did hold a discussion at our face-to-face meeting in
March involving several individuals with strong expertise in the area of
web security, where the majority of those people felt at the time that XDR
was preferred from a technical perspective due to security and simplicity
concerns.

It sounds like MS will not ship XHR2+AC within IE8 and is planning to go
ahead with XDR. IMO, not supporting XHR2 and AC in IE8 is understandable
since both only working drafts and clearly MS has a number of important
technical concerns, particularly relevant to security.

But for IE9/FF4/Safari4/Opera.NEXT, let's please get together on this
issue. I call on a good faith effort by the principal parties in this
discussion to meet face-to-face and start work to hammer out a unified
proposal that is acceptable to all. My sense is that the principal parties
are all trying to do the right thing for the Open Web, and the
disagreements are purely technical, which means the fundamental
requirements for compromise are present. Therefore, I suggest that sometime
soon there be a special meeting (could be a segment of the next F2F)
involving the primary contributors to AC along with the primary
contributors to XDR, where people meet and agree to work honestly and
openly towards a unified proposal. The first step is to get everyone in the
room and establish a sense of trust and good faith, which I'm not sure
exists yet. In order to bury the hatchets and proceed in an atmosphere of
trust, it may be necessary to toss out both AC and XDR (at least
temporarily), and establish process groundrules, and then review/update
objectives, use cases, and requirements (particularly with security
concerns), followed by an honest and open evaluation of existing proposals
(XHR2+AC, JSONRequest, XDR, ...) against those UCs and requirements.
Whether it is necessary to start from scratch probably can be determined at
the first meeting. The ultimate goal should be to achieve the same sort of
standards victory as is happening with postMessage(), where an important
new bit of functionality is getting into all of the major browsers, but
regarding the cross-site request feature, shoot for
IE9/FF4/Safari4/Opera.NEXT since it is too late for the 2008 generation of
browsers, which I would think means having a stable draft spec for the
compromise technology by end of 2008. It might be good to designate two
people as "drivers", where one of the two has been involved deeply with AC
and the other has been involved deeply with XDR, and for them to submit
jointly a compromise proposal (or proposals) that they think will sell to
all of the principal parties.

Jon




                                                                           
             Chris Wilson                                                  
             <Chris.Wilson@mic                                             
             rosoft.com>                                                To 
             Sent by:                  "public-webapi@w3.org"              
             public-webapi-req         <public-webapi@w3.org>,             
             uest@w3.org               "chaals@opera.com"                  
                                       <chaals@opera.com>                  
                                                                        cc 
             05/09/08 02:52 PM         Eric Lawrence                       
                                       <ericlaw@exchange.microsoft.com>,   
                                       Sunava Dutta                        
                                       <sunavad@windows.microsoft.com>,    
                                       Michael Champion                    
                                       <Michael.Champion@microsoft.com>    
                                                                   Subject 
                                       RE: IE Team's Proposal for Cross    
                                       Site Requests                       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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:chaals@opera.com]
Sent: Monday, May 05, 2008 7:30 AM
To: Sunava Dutta
Cc: Chris Wilson; Web API WG (public); public-appformats@w3.org; 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
<sunavad@windows.microsoft.com> 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:mjs@apple.com]
> Sent: Tuesday, April 29, 2008 5:01 PM
> To: Ian Hickson
> Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public);
> public-appformats@w3.org; 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