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

[Emily Stark <[e-mail]>]

Does anyone else have an opinion? If not, I'll probably go with text/plain.

On Wed, Jun 7, 2017 at 9:04 AM, Emily Stark <[e-mail]> wrote:

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