Re: Issue #356: Form-encode Expect-CT report bodies?

[Patrick McManus <[e-mail]>]

On Wed, Jun 7, 2017 at 3:39 PM, Martin Thomson <[e-mail]>
wrote:

> Can we go to first principles?
>
>
I can learn, forget, and relearn cors more times in a day than I care to
count :)

fwiw, it seems an inconsistent state of affairs here..

csp report-uri is similar.. afaict the current spec applies fetch (and
therefore cors) rules to it after mandating no credentials.. but also
afaict that's not the reality of implementations. The OCSP example has a
lot of similarities too, though the uri is less controllable (but after a
few layers from the PKI root who really knows..). when talking through the
basic cors principles (credential leakage, read-side leaks, write-side
triggers) I didn't really see a problem with a non content UA request doing
this based on a policy decision to implement a spec but I can certainly see
how every UA might come to a different conclusion. Indeed I went back and
forth a few times. So Emily, I certainly see where your use of
"jeopardizes" comes from with option a. This IETF forum is only likely to
muddy the waters further, I'm afraid as we aren't the keepers of cors.

which kind of brings us to the more httpbis parts of your issue - the self
described option b. Those are indeed gross. Perhaps more a little less
offensive, but still non ideal, workarounds would be:
 * an empty string origin request header and an
access-control-allow-origin: * response
 * content-type: text/plain (its not right, but seems strictly better than
a form)

hth. (I'm prepared to be told those are bogus too.)

-P







> The URL is controlled by a site.  Though it doesn't include ambient
> authority (I hope), it can still be used to poke at things on the same
> side of the firewall as a client.  That would seem to qualify it for
> CORS.
>
> On 7 June 2017 at 12:23, Patrick McManus <[e-mail]> wrote:
> > my gut reaction: why would an expect-ct report be more subject to cors
> than
> > something like OCSP? (assuming it wasn't driven directly from content)
> >
> >
> > On Tue, Jun 6, 2017 at 6:45 PM, Emily Stark <[e-mail]> wrote:
> >>
> >> I'm looking for some feedback on
> >> https://github.com/httpwg/http-extensions/issues/356.
> >>
> >> Expect-CT violation reports are currently specified as POST requests
> with
> >> JSON bodies. When implemented in a web browser, such reports should
> arguably
> >> send CORS preflights, because the content type is not CORS-safelisted
> >> (https://www.w3.org/TR/cors/#simple-header).
> >>
> >> But sending CORS preflights for these requests doesn't really make sense
> >> from a web browser architecture perspective: CT compliance is checked as
> >> part of certificate verification and connection setup, divorced from the
> >> context one needs to send a CORS preflight (such as an Origin header).
> This
> >> is not just a theoretical layering issue; implementing preflights for
> >> Expect-CT reports in Chrome would be pretty challenging.
> >>
> >> I only see two options to resolve this, both of which seem bad to me:
> >>
> >> a) Leave the reporting part of the spec as it currently is, and leave it
> >> up to the UA to decide whether further operations such as CORS
> preflights
> >> are needed for sending reports. This would basically leave it to us in
> >> Chrome to decide either that Expect-CT reports should not be subject to
> CORS
> >> restrictions, or that we should not ship reporting. (I'm uncomfortable
> with
> >> this option because it somewhat jeopardizes the only active
> implementation
> >> effort that I know of.)
> >>
> >> b) The disgusting option: disguise Expect-CT reports as form
> submissions,
> >> which are not subject to CORS preflighting. This would mean the report
> body
> >> is sent as hostname=blah&port=443&... or we could even just send
> >> expect-ct-report=<stringified JSON blob>.
> >>
> >> Thanks,
> >> Emily
> >
> >
>
>