RE: IE Team's Proposal for Cross Site Requests

Ian, in your response you claim four separate times that my statements are "FUD".  (I presume you mean http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt.)  I'll address those individually below, but your invective seems to confuse "Chris has different opinions/beliefs than me" with "Chris is distorting truth to try to game the system," or perhaps that's just the way you would like to paint me.

You claimed my message contained an "ultimatum" - defined by Webster's Revised Unabridged Dictionary as "A final proposition, concession, or condition; especially, the final propositions, conditions, or terms, offered by either of the parties in a diplomatic negotiation; the most favorable terms a negotiator can offer, the rejection of which usually puts an end to the hesitation."  (Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc.)

You are quite clearly incorrect in applying that word, as I stated no proposition, demanded no concession; and at any rate clearly stated that we plan to continue to participate in the cross-domain effort currently active in the WG regardless of the decisions made, in the hopes that Access Control + XHR can be improved; in fact, I stated no terms nor hesitation.  That time is clearly past.  I was correcting a misunderstanding.

You accuse us of blatant disregard for Web standards process, presumably if we ship XDR in IE.  I disagree.  We are ALLOWED, in fact, to disagree; in fact, if we believe a developing standard is a bad idea, we SHOULD speak up.  We are also NOT, in fact, required to have every feature we ship be based on an approved standard (or do I need to write out the list of features that are not in approved standards, but are in shipping versions of other browsers?  Isn't think how innovations like <canvas> happen?).  I do believe we must have good reasons to choose to go down a different path than a current standards effort - in this case, we believe we have quite good reason.

You appear to be unable to be objective about this matter, and would rather be indignant and self-righteous at our missteps than accept that perhaps, every once in a while, those complete dunces at Microsoft might just possibly have a point.  It's somewhat amusing to see how you react to proposals (even radical ones in conflict with current status quo) from people OTHER than Microsoft, e.g. Google's Blob proposal that overlaps with Opera and Mozilla work in the same area (http://lists.w3.org/Archives/Public/public-webapi/2008May/0106.html).

In your invective, you also (for the benefit of "other parties" not as clued in, apparently, as yourself) liken "what's going on here" to a poison pill, which I fail to understand.  http://en.wikipedia.org/wiki/Poison_pill would seem to suggest that you think Microsoft is taking some action that harms both us and the standards effort; however, I would point out 1) XDR doesn't harm Microsoft. 2) I just stated that we will continue working on the Web API group's proposal, in the hopes that it can become implementable for us in the future.

I want to be clear that the following paragraph is a personal statement by me, and should not be representing in any way to reflect the opinions, values or plans of Microsoft, nor should it reflect on them in any way.

I believe you just accused me personally of "poison pill" tactics to further the interests of Silverlight.  I will be offended by your accusation of moral bankruptcy once I stop laughing at the idea that I personally would do such a thing, given my personal feelings on Silverlight.  At any rate, please don't claim to be "explaining the situation" to anyone else when you have it so completely wrong, and don't impugn my moral character unless you really intend to do so.

Back to being a Microsoft employee: to address your individual statements:

>Sunava said last November that
>this feedback would be sent as soon as possible. As far as I know, nobody
>else spent six months writing up their feedback.

And we are to blame for that delay, yes.  However, despite your claims that we have not shared our concerns, I believe we have been sharing them, just at a higher level than you apparently want.

>> 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
>
>This is FUD -- there is nothing difficult to deploy about this, since
>cross-site XHR has never been available before.

You seem to equate "deploying" with "writing code," rather than any kind of understanding of the effects that deploying that code into markets that already use your software might have.  Shipping releases of IE to half a billion customers tends to give us that understanding in spades.

>> and [it is] challenging to imagine that there are no other headers in
>> use by servers anywhere around the world that might not be good to
>> access.
>
>Actually the great thing about the way the AC spec is designed is that we
>don't have to imagine this -- we can guarantee it. No headers under author
>control are ever sent to a server until the server opts in to this
>cross-domain mechanism explicitly.

You are presuming that all server implementations will understand the implications of this fully before they turn on cross-domain.

>This is all FUD -- the Flash issue is irrelevant here as we are by design
>avoding the policy file problem altogether (so we couldn't even have the
>old Flash 9 vulnerabilities if we tried),

I would point to the "DNS hardening" section of that post, and say yes you do have issues here.  It's not "the policy file issue," presuming you're referring to the policy file control issue, but the AC design does in fact have some other problems here.

>and the e-mail you cite above is
>just an e-mail from your team with vague unspecified security concerns,
>not a citation of vague requirements in the spec. (For example, Sunava in
>that e-mail suggests that same-site and cross-site XHR having different
>behaviour is bad design,

You seem to be missing the point, though I think Sunava actually said it fairly clearly in that post.  The problem is that XHR is one object; it works different vis-à-vis security depending on whether it's being used in a cross-domain or same-domain way.  That kind of switch has shown to be bad secure coding practice to us before, so we avoid designs with that potential vulnerable spot whenever possible.

>> 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)
>
>This is again FUD. Your team has been vaguely saying that these threats
>exist in the XHR2/AC proposal since last year, and yet nobody from
>Microsoft has ever actually shown a clear vulnerability. Reciting a litany
>of threat model terms without showing actual attack scenarios is not any
>kind of reasonable argument.

This sound like nothing short of demonstrating actual exploits against the design will demonstrate to you that it might be vulnerable.  Have you actually looked into secure coding principles at all?  Even, say, Writing Secure Code[1]?  Have you threat-modelled the intersection of AC and XHR2?  Are you aware that waiting until there's a clear code exploit is a bad time to start planning for a secure design?

>It is indeed different for no extra benefit.

I understand that you think there is no extra benefit.

>It is in fact a subset of the behaviour possible with XHR2.

That *IS* a benefit, when the superset includes potential security attack surface area, and even the smaller set is done in a way that has additional threats.

>(It's also worth reiterating the point made in the e-mail you cite above,
>namely that XDR has a slew of security problems itself, unlike the XHR2+AC
>proposal, despite your implication that XDR is "secure by design" and that
>XHR2+AC is "dangerous".)

I'm not getting into your mud-slinging campaign.

>> 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.
>
>I think it is pretty poor form to imply that Microsoft, who have only just
>returned to the browser space, somehow has experience that outweighs the
>experience of the three other browser vendors who are involved in the
>development of this specification, especially since those vendors have
>been active for far longer, and have a far better track record of security
>with their browsers.

Well, then there we disagree.  We have been shipping IE to more customers than all the other browsers put together for over a decade now.  We have had exponentially more security researchers focused on us than anyone else, because they follow the money, and the money goes with the user market.  We have spent tremendous amounts of effort and money restructuring our entire way of writing software in order to respond to these new aspects of our business.  You seem to think these experiences count for nothing, and we are a bunch of ignorant inexperienced wonks, rather than assuming that perhaps we've learned a few lessons given our unique experiences.

>> Finally, we disagree that the security concerns about XHR2+AC can be
>> addressed by mere tweaks to the technical details.
>
>It's hard for us to know whether they could or not since you and your team
>has continually failed to actually precisely specify what the security
>concerns _are_, despite promising them for six months!

Let's start with where I took this:

>> 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.
>> [9] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html

>
>This is further FUD. As Jonas pointed out in his reply to your e-mail, the
>attack you describe doesn't actually have anything to do with XHR2 [9a],

No, I think Jonas misunderstood how one would use DNS rebinding to create an attack.  In short, relying on cached credentials with no guarantee you're not talking to a different server is a bad idea.  XHR2+AC does this; XDR does not.  Is this unclear?

>Assuming you mean 0150, not 050 (which would never have been a valid

Yes, sorry, c&p error.

>thread), that e-mail has two replies, neither of which got a further reply
>from Microsoft.

Neither of which addressed the main issues from that post.  I would have expected either "oh yeah, that issue's on the list here: [blah]" or "that's not actually an issue, and here's why."

>Given that XDR has had a number of very serious security vulnerabilities
>described on this mailing list, you may wish to reconsider deploying XDR
>if security really is a goal. At least the following security problems
>have been detailed so far:

Sunava will address these issues.

-Chris

[1] http://www.amazon.com/Writing-Secure-Second-Michael-Howard/dp/0735617228/ref=pd_bbs_sr_3?ie=UTF8&s=books&qid=1210787965&sr=8-3

Received on Wednesday, 14 May 2008 18:44:28 UTC