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

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

From: Emily Stark <estark@google.com>
Date: Sat, 10 Jun 2017 09:29:05 -0700
Message-ID: <CAPP_2SaK=1JO8Oz=k=LuSLBVqGQ2ZUZ1JYufF_N7YJaNhk=iuA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, httpbis <ietf-http-wg@w3.org>, Anne van Kesteren <annevk@annevk.nl>
On Sat, Jun 10, 2017 at 1:55 AM, Martin Thomson <martin.thomson@gmail.com>

> For those who are reading this and eating popcorn, this is probably
> worth reading also... <https://github.com/whatwg/fetch/issues/530>
> On 9 June 2017 at 16:42, Emily Stark <estark@google.com> wrote:
> > As I said in my first message, implementing true preflights would violate
> > very core architectural principles in Chrome, and would jeopardize our
> > ability to ship an implementation. Maybe there are other implementors who
> > would like to chime in to the contrary, but as of now I'm not very
> inclined
> > to specify something that can't realistically be implemented.
> I wanted to poke at that a little.  Expect-CT is a header field, sent
> by a particular origin.  You store the tuple of origin, the expect CT
> mode (none, report, require), and the report URI somewhere.  Then when
> you connect to an origin you retrieve any stored tuple and compare
> what you get with what you expect.  I don't see how a stack would be
> unable to preflight at that point.  It has the information it needs
> for a preflight check.

What's missing is the origin that triggered the request: in Fetch language,
the request's client's origin, which populates the `Origin` header. Hence
the suggestion for a preflight with a null Origin header and
Access-Control-Allow-Origin: *. Which would be possible, and I think safe,
but a bit hacky. Probably not more hacky than any of the other solutions
under discussion, though. :)

Having the request's client's origin available at connection setup time
would require quite some gymnastics/re-design of the Chrome network stack,
which late-binds sockets and does not know which request(s) a particular
socket will be used for at connect time.

> I recognize that a particular piece of software might be constructed
> in a way that makes this difficult, but it can't be impossible.

> Question: how do you manage the checks when you are using alternative
> services?  I expect that you need to store a target origin for the
> connection attempt, rather than using the host and port or SNI and
> port that you are connecting to.  (This doesn't complicate things
> regarding the question at hand, but I don't see any text on this
> point.)

That's a good question, I have to think about that a bit.
Received on Saturday, 10 June 2017 16:29:59 UTC

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