Re: CORS performance

On both this, and CSP pinning, I find myself getting nervous about adding
an increasing number of headers which, when sent by any resource, impact
the security posture and functioning of an entire origin.   HSTS and HPKP
are somewhat "special" in that: they convey only a few bits of information.
are somewhat self-verifying (e.g. an https pin cannot be applied over http,
and a public key pin cannot be applied from a certificate without a
matching key) and unlikely to change.

For more complex, application-layer issues, are pinning headers really the
best and most manageable approach?

I think it is at least worth discussing the relative merits of using a
resource published under /.well-known for such use cases, vs. sending
"pinned" headers with every single resource.

Some of the things that argue against /.well-known are:

1) Added latency of fetching the resource.

For CORS pinning, this probably isn't an issue.  A client that has never
seen a pinned policy (by whatever mechanism it is delivered) will always
have to make a preflight, and servers will always have to respond
appropriately (rather than relying on the pinned policy) for legacy
clients.  So a client that knows about pinning can make a request to
/.well-known in parallel the first time it makes a CORS request to a given
host, and speed up all subsequent requests without any additional latency
on the first.

2) Clients hammering servers for non-existent /.well-known resources (the
favicon issue)

Again, probably not an issue for CORS, or not nearly as large an issue.
Clients can be configured to never ask for the CORS policy at an origin
unless/until they make a CORS request to that origin.  There is a question
of how long to treat a 404 as authoritative before re-polling, but it can
be fairly long without breaking anything.  We might also devise a "hint"
header that suggests a pinned policy is available, which would only be sent
along with preflight responses.


On disadvantages of headers:

1) Individual resources declaring policy for an entire origin can be
problematic and difficult to manage.

Doing this right, both to set a correct policy and police lower-privileged
resources from setting incorrect ones, in practice would require an
administrator to set up a filtering proxy in front of the entire origin,
which is more difficult and costly than simply locking down access to a
specific resource path to only administrators.

2) Lots of redundant chit-chat.

HTTP/2 header compression reduces the impact of this somewhat, and CORS
specifically could avoid sending pinning headers except on preflight
responses, but it does seem like a real concern.  How much long-term bloat
are we willing to accept on the network in order to save a few ms of
latency the first time you connect to a site?

-Brad



On Tue Feb 17 2015 at 10:42:20 AM Anne van Kesteren <annevk@annevk.nl>
wrote:

> Concerns raised by Monsur
> https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0260.html
> and others before him are still valid.
>
> When you have an HTTP API on another origin you effectively get a huge
> performance penalty. Even with caching of preflights, as each fetch is
> likely to go to a distinct URL.
>
> With the recent introduction of CSP pinning, I was wondering whether
> something like "CORS pinning" would be feasible. A way for a server to
> declare that it speaks CORS across an entire origin.
>
> The CORS preflight in effect is a rather complicated way for the
> server to announce that it can handle CORS. We made it rather tricky
> to avoid footgun scenarios, but I'm wondering whether that is still
> the right tradeoff.
>
> Something like:
>
>   CORS: max-age=31415926; allow-origin=*; allow-credentials=true;
> allow-headers=*; allow-methods=*; expose-headers=*
>
>
> --
> https://annevankesteren.nl/
>
>