Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Apr 18, 2010, at 4:48 AM, Julian Reschke wrote: In general, whitelists are bad because they close extension points. Please consider using a black list instead. But blacklists are worse for security, and security is the prime consideration here. Regards, Maciej
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Apr 18, 2010, at 9:56 AM, Julian Reschke wrote: On 18.04.2010 14:35, Ben Laurie wrote: In general, whitelists are bad because they close extension points. Please consider using a black list instead. In general, blacklists are bad because they open security holes. My experience is that people work around white lists by tunneling information through the parts they are allowed to use. That doesn't help at all, because it makes detecting and blocking the bad stuff even harder (example: tunneling other HTTP methods through POST using a method override request header). The security concern would be about accidental exposure, not deliberate tunneling of additional info. It's fine for two cooperating parties to send each other more information on purpose. Regards, Maciej
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On 19.04.2010 09:27, Maciej Stachowiak wrote: On Apr 18, 2010, at 9:56 AM, Julian Reschke wrote: On 18.04.2010 14:35, Ben Laurie wrote: In general, whitelists are bad because they close extension points. Please consider using a black list instead. In general, blacklists are bad because they open security holes. My experience is that people work around white lists by tunneling information through the parts they are allowed to use. That doesn't help at all, because it makes detecting and blocking the bad stuff even harder (example: tunneling other HTTP methods through POST using a method override request header). The security concern would be about accidental exposure, not deliberate tunneling of additional info. It's fine for two cooperating parties to send each other more information on purpose. Please consider this: Blocking unknown response headers means taking away an extension point. On the other hand, right now we are actually also discussing *adding* an extension header (U, for opt-in). This obviously would be impossible if another layer (say proxies) would already block that. Don't do to others what you don't want to be done to yourself. Blacklist things when there is a problem. Best regards, Julian
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On 19.04.2010 09:41, Maciej Stachowiak wrote: ... This obviously would be impossible if another layer (say proxies) would already block that. It wouldn't be impossible, it just wouldn't have the desired end-to-end effect. But proxies are already not allowed to remove random response headers. ... Whatever the rule is for proxies should be the rule for a software layer as well. What's relevant is the impact on the application. Don't do to others what you don't want to be done to yourself. Blacklist things when there is a problem. I think a whitelist with opt-in exceptions strikes the right balance between security and extensibility. You haven't provided any reasons why that's not good enough. I already did. If multiple layers blocked unknown response headers, and each needed a separate way to opt them back in, we'd be in trouble. Best regards, Julian
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On 19.04.2010 19:06, Tyler Close wrote: ... 4.2 Response Header Filtering Some HTTP servers construct an HTTP response in multiple stages. In such a deployment, an earlier stage might produce a uniform response which is augmented with additional response headers by a later stage that does not understand a uniform response header. This later stage might add response headers with the expectation they will be protected by the Same Origin Policy. The developer of the earlier stage might be unable to update the program logic of the later stage. To accommodate this deployment scenario, user-agents can filter out response headers on behalf of the server before exposing a uniform response to the requesting content. If the response includes a Uniform-Headers header with a value *, no response header filtering is required; otherwise, the user-agent MUST filter out all response headers other than the following: * Content-Encoding * Content-Language * Content-Length * Content-Location * Content-MD5 * Content-Range * Content-Type * Expires * Last-Modified * Location * Warning * any header whose name is the value of a Uniform-Headers header on the response Uniform-Headers = Uniform-Headers : ( * | #field-name ) The default members of the above whitelist include response entity headers defined by [HTTP], plus the Location and Warning headers. The Why are you ignoring other headers in the permanent registry? Why only allow entity headers? What the problem, for instance, with Allow (RFC 2616), Allow-Patch (RFC 5749) or Dav (RFC 4918)? default part of the whitelist does not include: headers used for credential authentication, such as WWW-Authenticate; nor headers that might reveal private network configuration information, such as Via; What's the rational for stripping all of the information in Via? nor caching headers, such as Age, which provide explicit information about requests made on behalf of other requesting content. What's the problem with Age, please clarify? ... Best regards, Julian
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On 19.04.2010 19:37, Tyler Close wrote: The default members of the above whitelist include response entity headers defined by [HTTP], plus the Location and Warning headers. The Why are you ignoring other headers in the permanent registry? Why only allow entity headers? What the problem, for instance, with Allow (RFC 2616), Allow-Patch (RFC 5749) or Dav (RFC 4918)? The default members of the whitelist define the minimum set of headers to allow. If the response entity is delivered, then at a minimum, the response entity headers should accompany it, assuming it is safe to do so. I manually vetted those headers. To support redirection, we need Location. Warning is needed in case the requesting content wants to reject stale responses. The server must then explicitly opt into anything beyond the minimum header set. Again: did you check all the headers in the permanent registry? If you did, why are the ones (which are just examples) missing? And what's the reason to default to strip general headers and response headers? default part of the whitelist does not include: headers used for credential authentication, such as WWW-Authenticate; nor headers that might reveal private network configuration information, such as Via; What's the rational for stripping all of the information in Via? Are you suggesting UMP specify an algorithm for filtering out only some Via header values? I'm concerned that by simply dropping the header, you profile too much. nor caching headers, such as Age, which provide explicit information about requests made on behalf of other requesting content. What's the problem with Age, please clarify? Content from one origin can tell exactly how long ago content from another origin requested the cached content. That's at least a privacy issue, and possibly a confidentiality issue. That appears to be an issue completely independently of CORS/UMP. If that's the case, it should be mentioned in the HTTPbis security considerations, but doesn't necessarily require blocking. Best regards, Julian
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Mon, Apr 19, 2010 at 10:55 AM, Julian Reschke julian.resc...@gmx.de wrote: On 19.04.2010 19:37, Tyler Close wrote: The default members of the above whitelist include response entity headers defined by [HTTP], plus the Location and Warning headers. The Why are you ignoring other headers in the permanent registry? Why only allow entity headers? What the problem, for instance, with Allow (RFC 2616), Allow-Patch (RFC 5749) or Dav (RFC 4918)? The default members of the whitelist define the minimum set of headers to allow. If the response entity is delivered, then at a minimum, the response entity headers should accompany it, assuming it is safe to do so. I manually vetted those headers. To support redirection, we need Location. Warning is needed in case the requesting content wants to reject stale responses. The server must then explicitly opt into anything beyond the minimum header set. Again: did you check all the headers in the permanent registry? If you did, why are the ones (which are just examples) missing? And what's the reason to default to strip general headers and response headers? Again, the model is to define a minimal whitelist and enable servers to explicitly extend the minimal whitelist. The default members of the whitelist only exist as a convenience, so that servers don't have to explicitly list them on every response. Also, asking a static specification to keep up with a mutable registry is not feasible. default part of the whitelist does not include: headers used for credential authentication, such as WWW-Authenticate; nor headers that might reveal private network configuration information, such as Via; What's the rational for stripping all of the information in Via? Are you suggesting UMP specify an algorithm for filtering out only some Via header values? I'm concerned that by simply dropping the header, you profile too much. It is not simply dropped, it can be enabled by any server or proxy in the request path. nor caching headers, such as Age, which provide explicit information about requests made on behalf of other requesting content. What's the problem with Age, please clarify? Content from one origin can tell exactly how long ago content from another origin requested the cached content. That's at least a privacy issue, and possibly a confidentiality issue. That appears to be an issue completely independently of CORS/UMP. It is not at all independent. There was no way to access the Age header cross-origin before CORS/UMP. If Age is allowed by default then any page can ask What did you know and when did you know it?, which is, of course, a powerful question. If that's the case, it should be mentioned in the HTTPbis security considerations, Last I heard, HTTPbis punted on explaining anything to do with the Same Origin Policy security model that has evolved around HTTP. I asked them to and they refused. but doesn't necessarily require blocking. Again, it's not blocked. It just requires an explicit opt-in. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Apr 19, 2010, at 10:06 AM, Tyler Close wrote: Uniform-Headers = Uniform-Headers : ( * | #field-name ) [...] Are Apple and/or Firefox interested in implementing the above? Does mnot or other HTTP WG members consider the above a satisfactory solution to ISSUE-90? I'm interested in implementing a feature along these lines if it goes into CORS. If it's UMP-only, then no, and I would object that it violates the subset relation. I am also not sure the * value is a good idea. It is tempting in its convenience but seems likely to cause unintended consequences. Regards, Maciej
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Mon, Apr 19, 2010 at 11:30 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2010, at 10:06 AM, Tyler Close wrote: Uniform-Headers = Uniform-Headers : ( * | #field-name ) [...] Are Apple and/or Firefox interested in implementing the above? Does mnot or other HTTP WG members consider the above a satisfactory solution to ISSUE-90? I'm interested in implementing a feature along these lines if it goes into CORS. If it's UMP-only, then no, and I would object that it violates the subset relation. I am also not sure the * value is a good idea. It is tempting in its convenience but seems likely to cause unintended consequences. I agree with everything Maciej said. This time. :) / Jonas
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Mon, Apr 19, 2010 at 11:39 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Apr 19, 2010 at 11:30 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2010, at 10:06 AM, Tyler Close wrote: Uniform-Headers = Uniform-Headers : ( * | #field-name ) [...] Are Apple and/or Firefox interested in implementing the above? Does mnot or other HTTP WG members consider the above a satisfactory solution to ISSUE-90? I'm interested in implementing a feature along these lines if it goes into CORS. If it's UMP-only, then no, and I would object that it violates the subset relation. I am also not sure the * value is a good idea. It is tempting in its convenience but seems likely to cause unintended consequences. I agree with everything Maciej said. This time. Thanks for the quick response time. If this is a good feature, shouldn't the pressure be on CORS to adopt it, rather than for UMP to drop it? Otherwise, it might seem politics are overriding technical virtue. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Mon, Apr 19, 2010 at 11:47 AM, Tyler Close tyler.cl...@gmail.com wrote: On Mon, Apr 19, 2010 at 11:39 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Apr 19, 2010 at 11:30 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2010, at 10:06 AM, Tyler Close wrote: Uniform-Headers = Uniform-Headers : ( * | #field-name ) [...] Are Apple and/or Firefox interested in implementing the above? Does mnot or other HTTP WG members consider the above a satisfactory solution to ISSUE-90? I'm interested in implementing a feature along these lines if it goes into CORS. If it's UMP-only, then no, and I would object that it violates the subset relation. I am also not sure the * value is a good idea. It is tempting in its convenience but seems likely to cause unintended consequences. I agree with everything Maciej said. This time. Thanks for the quick response time. If this is a good feature, shouldn't the pressure be on CORS to adopt it, rather than for UMP to drop it? Otherwise, it might seem politics are overriding technical virtue. I didn't mean to exert any pressure on UMP to drop it. Sorry if you read otherwise into what I said. / Jonas
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On 19.04.2010 20:30, Tyler Close wrote: ... Again: did you check all the headers in the permanent registry? If you did, why are the ones (which are just examples) missing? And what's the reason to default to strip general headers and response headers? Again, the model is to define a minimal whitelist and enable servers to explicitly extend the minimal whitelist. The default members of the whitelist only exist as a convenience, so that servers don't have to explicitly list them on every response. Also, asking a static specification to keep up with a mutable registry is not feasible. ... Yes. That's exactly the reason why a whitelist is wrong choice. Best regards, Julian
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Apr 19, 2010, at 12:13 PM, Jonas Sicking wrote: On Mon, Apr 19, 2010 at 11:47 AM, Tyler Close tyler.cl...@gmail.com wrote: On Mon, Apr 19, 2010 at 11:39 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Apr 19, 2010 at 11:30 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2010, at 10:06 AM, Tyler Close wrote: Uniform-Headers = Uniform-Headers : ( * | #field-name ) [...] Are Apple and/or Firefox interested in implementing the above? Does mnot or other HTTP WG members consider the above a satisfactory solution to ISSUE-90? I'm interested in implementing a feature along these lines if it goes into CORS. If it's UMP-only, then no, and I would object that it violates the subset relation. I am also not sure the * value is a good idea. It is tempting in its convenience but seems likely to cause unintended consequences. I agree with everything Maciej said. This time. Thanks for the quick response time. If this is a good feature, shouldn't the pressure be on CORS to adopt it, rather than for UMP to drop it? Otherwise, it might seem politics are overriding technical virtue. I didn't mean to exert any pressure on UMP to drop it. Sorry if you read otherwise into what I said. Me neither. I don't intend to pressure anyone in particular. I'd like to come to consensus on a solution and ideally add it to both specs. - Maciej
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
I have been studying CORS ISSUE-90 http://www.w3.org/2008/webapps/track/issues/90, so as to bring UMP into line with this part of CORS. I can't find any pattern or rationale to the selection of headers on the whitelist versus those not on the whitelist. Does anyone know where this list came from and how it was produced? If I produce a more comprehensive whitelist for UMP will CORS follow my lead? --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
On Wed, Apr 14, 2010 at 9:41 AM, Tyler Close tyler.cl...@gmail.com wrote: I have been studying CORS ISSUE-90 http://www.w3.org/2008/webapps/track/issues/90, so as to bring UMP into line with this part of CORS. I can't find any pattern or rationale to the selection of headers on the whitelist versus those not on the whitelist. Does anyone know where this list came from and how it was produced? If I produce a more comprehensive whitelist for UMP will CORS follow my lead? The following whitelist includes all end-to-end response headers defined by HTTP, unless there is a specific security risk: # Age # Allow # Cache-Control # Content-Disposition # Content-Encoding # Content-Language # Content-Length # Content-Location # Content-MD5 # Content-Range # Content-Type # Date # ETag # Expires # Last-Modified # Location # MIME-Version # Pragma # Retry-After # Server # Vary # Warning Does anyone object to making this the new whitelist for both CORS and UMP? --Tyler
Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]
Anne - for any of the issues you want to close, please propose a resolution with at least a 1-week review period. Tyler - do any of these CORS issues apply to UMP? -Art Barstow On Apr 7, 2010, at 10:22 AM, ext Anne van Kesteren wrote: On Wed, 07 Apr 2010 16:06:55 +0200, Arthur Barstow art.bars...@nokia.com wrote: What is the status and plan to get CORS ready for Last Call? I've mostly been waiting to see what happens with UMP. What I've heard so far from various implementors is that they want to keep CORS and add the ability to XMLHttpRequest for credential-less requests via the constructor. But I might be missing something. I see the following related Raised Issues: Reduce the length of the header names? http://www.w3.org/2008/webapps/track/issues/89 This is not possible I think. SPDY or some such should be of help here. Anyway, it is still open because mnot wanted some kind of official WG decision. Exposing more (~infinite) response headers http://www.w3.org/2008/webapps/track/issues/90 I've been trying to find out which solution implementors prefer, but without much luck so far. confused deputy problem http://www.w3.org/2008/webapps/track/issues/108 We discussed this to death. CORS does not define the effect of the credentials flag in sufficient detail http://www.w3.org/2008/webapps/track/issues/114 I defined this. And the latest ED includes 3 red block Issues. They all indicate the need for other specifications to move forward. URL, HTTP, and whatever specification ends up defining origin. I.e. editorial and should in theory not block progress. -- Anne van Kesteren http://annevankesteren.nl/
