SV_MEETING_TITLE -- 02 Jul 2008

<chaalsXO> s/work?/work/

<chaalsXO> SD: * doesn't clearly say what it allows - everyone can access, or one person can access everything?

<chaalsXO> JS: Out of context yes, but it should be clear since everything about the spec clarifies it

<chaalsXO> SD: OK

<chaalsXO> JS: If we drop * with cookies then this might go away

<chaalsXO> JS: One big thing remaining is access control path canonicalisation

<chaalsXO> ... concern about granting by path - granting from one URI to cover a whole set...

<chaalsXO> EL: Flash had a problem doing this path-based granting. You can encode hex sequences for ../ and make path-matching security holes

<chaalsXO> .. e.g. /bad/visitor/* can be mapped to /bad/visitor/../../../../victim/secret...

<chaalsXO> JS: I don't knowif flash are doing anything to mitigate this.

<chaalsXO> ... have a proposal, where anything that climbs upwards gets auto-denied.

<chaalsXO> ... there are very few use cases for this.

<chaalsXO> EL: You have toensure that the servers accurately trap this correctly...

<chaalsXO> ... there are attacks based on gps in the normalisation process.

<chaalsXO> JS: Not happy just saying servers should solve this

<chaalsXO> IH: The only sane thing is to make this apply to the entire domain, as a waay to avoid the problem

<chaalsXO> JS: There is a risk with that where too much access is enabled ...

<chaalsXO> IH: The alternative is requiring a lot more pre-flight traffic

<chaalsXO> JS: I am happy leaving this out for now

<chaalsXO> IH: Could make sense

<chaalsXO> ZY: If the server relies on the preflight, you get a problem

<chaalsXO> JS: Right. But you should not be able to do that - an anyway the risk is bad enough to avoid anyway

<chaalsXO> MJS: Seems like a tricky space to get into. Maybe we should start out only allowing options on a single resource

<chaalsXO> DS: Would be good to note the rationale in the spec...

<chaalsXO> IH: The nasty case is atompub, where you have zillions of requests...

<chaalsXO> JS: We don't have a nice solution here. Setting it on the root seems bad too.

<chaalsXO> IH: I really want this feature, but I don't see a good way to do it and think we probaby have to punt it to v2

<chaalsXO> DS: Does that constrain us?

<sunava> http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html#policy_files

<chaalsXO> IH: No, we just have nothing and can add the feature

<chaalsXO> SD: You cn send stuff through headers to the PI?

<chaalsXO> EL: THink this issue is covered

<chaalsXO> ... related concern is the restriction of setting the range header outbound.

<chaalsXO> JS: right - I implemented something that would allow that exploit...

<chaalsXO> ... we could note in the spec that this is an implementation bug. I have smoe concerns about the PI, but that's for tomorrow...

<chaalsXO> ... possibly other headers have similar concerns

<chaalsXO> EL: Interesting because this is something that has a different effect in XS XHR than in local XHR

<chaalsXO> AvK: RANGE requires opt-in

<chaalsXO> JS: We couldwhite-list this. Watch for range...

<chaalsXO> AvK: Sounds messy to spec

<chaalsXO> JS: Sure, but we will have to point it out anyway...

<chaalsXO> AvK: Think you want to be able to see 206 responses...

<chaalsXO> IH: If you get a partial response, then if it doesn't start at byte 1, don't look at the PI

<chaalsXO> ... if we take PI out of the equation we may not need to worry.

<chaalsXO> AvK:Do we wnt to take headers in XBL?

<chaalsXO> IH: We keep it inAC, but special-case it out sometimes.

<chaalsXO> SD: Browsers could get header to identify x-domain cookies, not give them out mistkenly

<chaalsXO> JS: Any infastructure wouldstop working if it required new headers

<arun> scribenick: arun

SD: (citing Jonas' feedback) This is "extra bad" considering that you are violating the HTTP spec.

<chaalsXO> MJS: There are several cookie issues - good topic for tomorrow

JS: I think x-site request forgery issues that exist on the web today exist for very different reasons today.
... outside of Access Control.
... it is hard to mitigate it.
... I don't think that CRSF applies directly to this.

Bryan: I think that if we implement this exactly as you're saying, it will increase CSRF.
... it's not just that your'e sending an attack. Now you can process the response, and can take multiple steps on the response.
... what's possbie right now is you can send a request, but you can't really act on the response. If we go down this road (XHR2 + AC) it enables an attacker to set up a multistage send/process cycle, which is impossible today.

MJS: on the other hand, access control gives you mitigation mechanisms to check origin, etc.

JS: this is applicable to URIs where people specifically opt in to Access Control. You have a resource that accepts requests, but when they set up that resource, they didn't conceive that it could be accessed x-site.

MJS: you need 2 factors. 1. a process against CSRF but 2. opened up access control to site in a way you didn't intend to.
... those are certainly possible, but not likely scenario.

JS: Big risk -- sites do opt in to access control on parts of their URI space that they didn't mean to.

Bryan: difference of XDR is that sites aren't sending Cookies.

JS: mistakes can happen; what we can do is make tools good, language clear enough, do more fine-grained control. That's about all we can do. XDR does have a small risk, but it also supports a smaller feature set. No matter what we do to expand that feature set, we introduce mistakes.

Bryan: by increasing the scope of the functionality, we need to make an informed decision about [security issues].

SD: (citing Jonas' feedback) access control follows user agents privacy policies.
... which user agents?

JS: I think spec. text should reflect that user agents privacy policy should be followed.

SD: one more high level issue.... one was preflights. any more questions on preflights?

EL: In my opinion, virtually everything depends on the preflight. Sounds like making preflight more restrictive, etc., are [answered]. Responses to OPTIONS request are not cacheable.
... if am a server Fidelity with partner PayPal, response otherwise cacheable. Some intermediary proxy would cache that response. No preflight required. No actual concern here, unless Fidelity were to mistakenly overgrant permissions in headers. Server that chooses to participate in OPTIONS has to be worried that intermediate proxy will cache response.

JS: right now a server can say allow " * ". If that gets cached on the way, that would be bad.

MJS: do proxies respect VARY header?

EL: it's a HTTP/1.1 feature.
... IE's support for VARY is dismal.
... servers may be silly to allow " * " for desirable domains.

JS: we always make OPTIONS requests with cache-control no cache. We can do this.
... I'm more concerned than you are here.

EL: I don't know if you know this, but beta2 does send origin (like access control)

MJS: would you (Microsoft) implement a subset of access control that matches XDR's header exchange, if it is a clean subset ?

EL: on the one hand, I understand the appeal, on the other hand, I worry about mixing our implementation with your spec.

JS: I think we can construct the spec. in such a way that you could use the same syntax, and not impede the path forward. The one concern is that it makes it very attractive for people to limit themselves to the subset that IE supports.

ZX: if the spec clearly spells out that some UA may support this mode, and that's limited, it seems conceivable.

SD: we are serious about interoperability. We'd like to see how can do access control with XDR. In IE8 this will be very difficult.

ZX: whatever change we can do with IE8 is very small.

JS: it's an incompatibility because of POST not being preflighted in XDR.

EL: it's an incompatibility among myriad.

MJS: on the XDR implementation, you wouldn't get the preflight. You're opting into two different security models. In the GET case we could construct a similar path, but not with POST.

adjourn meeting

<sicking> Agenda: Resolve outstanding issues on Access-Control

<chaals> http://www.w3.org/2008/webapps/track/products/7

<chaals> access control issues

<mjs> http://www.w3.org/2008/webapps/track/issues/open

<sicking> mjs: some issues raised yesterday not yet in the right product

<mjs> issues 10-14

<sicking> mjs: such as allowing implementations to override the spec with implementation specific security features

<chaals> http://www.w3.org/2008/webapps/track/products/7 -> acess control issues

<sicking> chaals: issues raised yesterday should be in correct product

<sicking> sicking: do we have an issue on what mjs just brought up

<chaals> ISSUE: Should Access-control allow DNS binding defense?

<trackbot> Created ISSUE-29 - Should Access-control allow DNS binding defense? ; please complete additional details at http://www.w3.org/2008/webapps/track/issues/29/edit .

<sicking> mjs: there are two related issues. 1. does the spec allow for DNS rebinding defense. 2. more general, does the spec allow for other defences

<sicking> chaals: given that implementations are going to do that anyway, should the spec allow that

<chaals> ISSUE: Should spec have wording to recognise that User Agents may implement further security beyond the spec?

<trackbot> Created ISSUE-30 - Should spec have wording to recognise that User Agents may implement further security beyond the spec? ; please complete additional details at http://www.w3.org/2008/webapps/track/issues/30/edit .

<sicking> mjs: saying 'caching is allowed to be ignored at any time' will allow for many defences without telling authors that "anything can happen due to security"

<sicking> chaals: lets cover this issue right away since there is consensus

<sicking> sunava: spec seems like it's geared towards browsers rather than developers

<sicking> sunava: how can we ensure that security notes in the spec and elsewhere reaches authors

<sicking> chaals: having information in spec about things that happen in real world is useful.

<tlr> thx

<sicking> arun: tlr raised issue about DNS defense mechanism

<sicking> mjs: not a big deal if we're not requiring that particular defense mechanism but rather just allow for DNS rebind defenses

<chaals> scribeNick: sicking

<arun> arun: fair enough :-)

<tlr> ack re mjs

<chaals> Proposed resoultion: Specifications SHOULD include language recognising that there may be extra implementation detail for security...

anne: we need to figure out what changes to make to the spec

sicking: we can just mention that in the section on caching

mjs: there are two places where we wanna note things
... make sure that the caching rules don't mandate caching
... other thing is mention in security consideration section we should mention that implementations may do this
... we should changes things to SHOULD or MAY to allow for not caching

chaals: implementions should send information about where they want to deviate from spec so that we can get those things into spec

<chaals> RESOLUTION: (provisional, like all real-time resolutions) We will have language noting possible implementation differences, where appropriate. This closes ISSUE-30

mjs: both do what chaals said, and make changes for caching

sicking: Access-Control-Policy-Path got more or less resolved yesterday

mjs: since we can't secure it we should punt it for now

chaals: sounded like google was ok with dropping it

Hixie: well, anyone who does atompub, including google, wants it. But if we can't make it secure there is no point in pushing it

<chaalsXO> RESOLUTION: We drop access-control-policy-path. This closes ISSUE-12

<chaalsXO> RATIONALE: We can't find a decent way to keep it secure yet...

chaalsXO: ISSUE-25

mjs: i think the best suggestion yesterday was to limit amount of time that something can be cached. Such as a day

chaalsXO: what i liked about the other suggestion yesterday, explicit revocation, is that it matches human behavior
... when you mess something up, you can fix it

mjs: the problem is you still have to protect yourself since the first request can be harmful

sam: since you need to protect yourself against the first request anyway, doesn't seem like explicit revocation buys that much

sunava: is origin filtering foolproof?

Hixie: this is all for authenticated requests. All other requests are always possible server-to-server. For those origin filtering should be ok

<tlr> incidentally, +1 to hixie on that one

kriszyp: can we define a status code for revocation

mjs: seems like a 403 could mean revocation

anne: currently the spec is status code agnostic, i sort of like that

Hixie: it makes sense to flush the cache on any 400 status

mjs: that makes sense

Hixie: servers can always deny on "Origin"

sicking: it would have to be something other, origin isn't always cross-site

Hixie: we should have a cross-site-only header

sicking: i agree

weinig: sounds like we've got from not having a revocation mechanism, to having one, which is status code

shepazu: if we're going to have a max time limit. We should look at if there's something less arbitrary than a day

mjs: having a timelimit sounds like a defence in depth mechanism that makes sense

Zhenbin: server will have to take action anyway

sunava: are you worried about extra complexity?

<Hixie> (actually, on second thoughts i think that Origin is enough, we don't need an xhr2-specific header. You'd just have to filter on Origin != expected origin and return 403.)

<anne> (I agree)

mjs: we should go back to why we suggested this in the first place
... there's two concerns:
... someone misconfiguring the server with a long timeout
... someone uses man-in-middle to insert a response with a huge timeout to poison cache for a long time

Hixie: a usecase for huge timeout is google analytics. We want to track using the same uri for a long time with as little overhead as possible

anne: seems like if a user clears there normal caches, then they would expect this cache to be cleared too

mjs: seems like there are pros and cons to a upper limit
... if you make a misstake and don't know how to defend yourself you'll be fine within a day by default
... the downside is that for things like the analytics example they would get more requests

sicking: i think we'll set a limit in mozilla, sounds like the tradeoff is good enough

mjs: optimization tools might recommend to set all your caching limits really high. operators might follow that without fully understanding the consequences.

chaalsXO: sounds like we're argining about MUST vs. SHOULD

Zhenbin: still sounds like an unneccesary measure

shepazu: sounds like it would be good to have interoperability

sicking: i don't think interoperability is an issue, either way servers shouldn't set too long timeouts

weinig: should we mandate or recommendation that switching proxies clear the cache

chaalsXO: should we recommend a short timeout?

sunava: i agree

sicking: i agree

anne: i agree

<weinig> by recommend I mean SHOULD or MAY

adjourn

<chaalsXO> RESOLUTION: We recommend ('should') a short timeout (with an explanation of why).

<weinig> ISSUE: Allow POST without a preflight with headers in a whitelist

<trackbot> Created ISSUE-31 - Allow POST without a preflight with headers in a whitelist ; please complete additional details at http://www.w3.org/2008/webapps/track/issues/31/edit .

<sunava> sunava is scribing

<arun> scribenick: sunava

<Maciej> cache will be constatly flushed. especially in mobile areas

<arun> sunava, use abbreviations/initials, e.g. maciej = mjs

<jonas> is fine with leaving it out. Implementations can do it

ok, sure

<arun> sunava, also use a colon ":"

C.M: I expect to put in drafts people expecting to call for review of specific aspects, do we add feedback in draft
... I dont think we need a resolutiononthis
... Do we resolve 4xx?

M.S: I dont think we MUST not maintain cache after 4xx

C.M: 5xx may be reasonable to cahce
... I dont want to have arequirement to drop cache in 5xx

<arun> AvK: if a server doesn't respond with an access control header(s), discard response/don't cache

M.S: Revoking preflight based on access control not in response it not sound

Zx: There appears to be a substatus code, this is the case for IIS. Substatus code tells why it is forbidden. Are we using thesubstatus code

AvK: I dont think this is part of HTTP
... A lot of these are IIS specific

Js: If we're not differentiaing between 4xx codes, it doesnt make sense to differentiate based on dots

Ih: We should not make this any different for caching

Zx: 407 means proxy auth required
... For example

IH: You would not have anything cached if this happened

Zx: Not all access are equal

Js: It doesnt change the functionality, we just need to redo the OPTIONS request on next

AvK: The spec requires that if you perform the access control request, if it fails you remove the entry
... So it doesnt depend on status code

<arun> arun: from spec -- " Perform an access control check. If it returns "fail", apply the generic network error steps. Otherwise, if it returns "pass", terminate this algorithm and return with the status flag set to "success". Do not actually terminate the request. "

Cm: This issue resolved

<arun> arun: umm, sorry, i pasted the wrong "otherwise".

<arun> arun: Perform an access control check. If it returns "fail", remove the cache entry, then apply the generic network error steps. Otherwise, if it returns "pass", terminate this algorithm and return with the status flag set to "success". Do not actually terminate the request.

s.w: Bag of worms is next?

Zx: I want to talk about caching,for the GET case, theres not preflight
... YOu do GET with credentials
... If credentials are cached, the cache may say its allowed if the results for the GET are returned from the cache

Js: What a server should do, ( a server that returns different allow headers based on origin) , varying based on origin header. IF a server does that, it should sent a VARY based on origin header.

Ms: If the origin header is the same, it doesnt require any extra validation

Js: If you go to A, says OK, go to A again, then its OK to resue one

Mjs: Most proxies have good support for vary header
... In browser cache implementations sometimes they dont respect vary header

Js: If server sets vary header, caching should work OK
... This is kind of the wildcarding issue, if you go to site A and server says allowed *, and go to B and it should be allowed, then we recommend not including cookies...

Sd: With XDR we decided to have a different cache pool
... Even though it is public data in an anonymous request
... Instead of relying on the server to do the right thing.

Zx: To be very secure, I would recommend separating the cache pool
... But the challenge here would be then you need a different cache pool for a different origin, hmmm...

Js: I'm not following

Zx: First case you talk about, server may say you need to send a vary

Js: Let's say it addition to that we dont allow wild cards with cookies

<chaalsXO> SD: That could work in XDR, but you need a seperate cache for every origin

<chaalsXO> ZX: We still get access control list on get...

<chaalsXO> AvK: could be, not necessarily

<chaalsXO> MJS: Or allow a single response to avoid exposing policy.I think AC requires a specific cache for the OPTIONS response.

can anyone scibe for this?

im particpating

its a bit hard..(I'll re-pickup scribing in a sec)

<chaalsXO> scribenick: kriszyp

<chaalsXO> scribenick: kris

JS: Recognize that there can be concerns with private data be exposed from caches where an entry is cached from a normal same-origin request with cookies and then it can be possibly be returned for a CS request (assuming no Vary header)

IH: Cache: Private should help with proxy caches

SD: You need separate cache pools for each origin to be safe

JS: You only need two cache pools (normal cache and cross-site cache)

<Hixie> ("Cache-Control: private" is the header I mentioned earlier)

JS: You can either provide a list of acceptable sites in the header, or you can do it server-side with the Origin header + Vary: Origin

SD: Does this really work in practice?

AVK: Yes

<chaalsXO> ZX: Think that could solve the problem

<chaalsXO> KZ: Think this would be a good way to do this - important usecase

arun: Can someone propose resolution language?

Js will do it

<sicking> Proposed Resolution In order to avoid caching issues we need the following: UAs need to have a separate cache for cookie-less requests. We should recommend servers to use the Vary header if their Access-Control list varies with the Origin header. Further, if we adopt the don't-allow-wildcardging-with-cookies suggestion that will reduce the risk of server misconfigurations

<chaalsXO> RESOLUTION: In order to avoid caching issues we need the following: UAs need to have a separate cache for cookie-less requests. We should recommend servers to use the Vary header if their Access-Control list varies with the Origin header. Further, if we adopt the don't-allow-wildcardging-with-cookies suggestion that will reduce the risk of server misconfigurations

<MikeSmith> scribenick: MikeSmith

RESOLUTION: In order to avoid caching issues we need the following: UAs need to have a separate cache for cookie-less requests. We should recommend servers to use the Vary header if their Access-Control list varies with the Origin header. Further, if we adopt the don't-allow-wildcardging-with-cookies suggestion that will reduce the risk of server misconfigurations

- DRAFT -

SV_MEETING_TITLE

02 Jul 2008

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output