W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 7 Jun 2017 15:39:46 +0200
Message-ID: <CABkgnnUVYB1Dqh4efe25bKx=-2iOBXHZg=3fgXjvbRn28b6nuw@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Emily Stark <estark@google.com>, httpbis <ietf-http-wg@w3.org>
Can we go to first principles?

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 <mcmanus@ducksong.com> 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 <estark@google.com> 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
>
>
Received on Wednesday, 7 June 2017 13:40:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC