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

[Emily Stark <[e-mail]>]

Re: CSP and OCSP, yes, those are open issues as well. Indeed, the Expect-CT
issue spawned a long and as-yet-unresolved debate about OCSP:
https://github.com/whatwg/fetch/issues/530

For CSP, the plan is to move reporting to the in-progress Reporting API,
which was intended to send CORS preflights but doesn't currently in either
spec or implementation. The spec issue is
https://github.com/WICG/reporting/issues/41, and it's still an open
question how preflights would be implemented in Chrome.

HPKP reporting has the same issue. Whatever we do for Expect-CT would most
likely make sense to apply for HPKP reports as well.

I would be okay with either of your proposed workarounds. I lean slightly
towards text/plain because I suspect the empty-Origin-header proposal will
lead to implementors doing special-purpose implementations of a subset of
CORS for this purpose, skipping preflight caching and such.

On Wed, Jun 7, 2017 at 8:36 AM, Patrick McManus <[e-mail]>
wrote:

> 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
>> >
>> >
>>
>>
>