Intent to Ship: Expect-CT HTTP header

[Emily Stark]

Contact emails

est...@chromium.org

Spec

https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct-01

Did not request a tag review based on advice that TAG is not a good fit for features that are not exposed to DOM/CSS/HTML

Summary

This feature allows sites to opt in to Certificate Transparency enforcement. It gives sites a way to get stronger security benefits out of CT than they would be able to otherwise. It also helps move the ecosystem along to April 2018, when CT will be required for all new publicly trusted certificates. (For example, large/complicated CT deployments can use Expect-CT to ensure that they are working smoothly before April, when they might find out the hard way that they aren't.)

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/tgn5R-58iek/Q6YCnu0RFQAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Debuggability

The Expect-CT HTTP header will show up in DevTools like any other HTTP header. In M62, to improve debuggability, we'll add a section to chrome://net-internals/#hsts to allow developers to inspect Expect-CT state.

Interoperability and Compatibility Risk

(a) Firefox has given public positive signals (see below) and has been involved in deciding design issues on the specification.

(b) By shipping Expect-CT, Chrome will be further committing to its CT policy, e.g. how many SCTs are required and from what CT logs. This could make it more difficult to change Chrome's CT policy or list of trusted logs without breaking existing sites.

(c) Another interop risk is that it is up to the browser to decide details of the CT enforcement policy. Another browser vendor could choose to ship CT with a policy such that a site satisfies their policy but not Chrome's, or vice versa.

(d) Expect-CT is an opt-in security feature, so shipping it will not pose a compat risk to existing web content. However, once shipped, we will have to consider any changes to the spec carefully. For example, changing the syntax could cause existing Expect-CT sites' headers to no longer be recognized by Chrome, or could cause site owners to deploy headers that work in a new version but cause their site to be broken in an older version of Chrome.

Regarding (b) and (c), it's worth nothing that to some extent, these risks apply in general to the broadening of CT enforcement, and are not specific to Expect-CT. Chrome's CT policy is already widely applied (for Symantec certificates, and for granting Extended Validation UI in the omnibox) and is soon (April) to be applied to all newly issued publicly trusted certificates. Changes to the policy already have to be carefully considered and widely communicated. Future policy changes will likely be deployed in a date-based way, so that they apply to new certificates and do not break existing certificates. Overall, we think that the Expect-CT will help the ecosystem mature and reduce breakage when the CT requirement date hits in April, outweighing these risks.

Edge: No signals

Firefox: Public support (https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0767.html)

Safari: No signals

Web developers: Positive (https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83fIh952e_szZVypO4AvQ/edit?disco=AAAAAvQ8ScU)

Is this feature fully tested by web-platform-tests?

No, as this is an HTTP header specified in the IETF and not exposed to DOM/CSS/HTML, I'm not sure this belongs in web-platform-tests.

OWP launch tracking bug

https://crbug.com/679012

Entry on the feature dashboard

https://www.chromestatus.com/feature/5677171733430272

[Emily Stark]

I just remembered there's another compatibility aspect I wanted to draw attention to, which is the somewhat ugly issue of CORS preflights for reports. This is a nuanced issue and I've done my best to summarize all the nooks and crannies succinctly, but please let me know if any of the below isn't clear.

Expect-CT offers a reporting option: a site can register a reporting endpoint, and when it violates the browser's CT policy, the browser will send a report to the reporting endpoint to help the site owner discover and debug CT misconfigurations. This is similar in spirit to CSP reports, HPKP reports, and the not-yet-shipped Reporting API. All of these reports arguably ought to trigger CORS preflights, because they are requests initiated by web content with a non-CORS-safelisted Content-Type header. But none of CSP, HPKP, or the Reporting API implementations do currently trigger preflights. For Expect-CT, the spec leaves it up to the UA to decide whether and how to send preflights for reports.

I didn't want to introduce yet another ad-hoc CORS violation with Expect-CT. But on the other hand, Expect-CT is enforced as part of certificate verification, and it's not particularly viable to construct a meaningful Origin header to send in a preflight request at that point. (Certificate verification is part of connection setup, and the socket may not be bound to an actual request yet.) Therefore, Chrome implements a CORS preflight with a null Origin header that expects an `Access-Control-Allow-Origin: *` header in response before sending Expect-CT reports (which is a perfectly reasonable ACAO header for a publicly accessible reporting endpoint to send).

This null Origin header is a bit ugly, but I believe it's the best option for compatibility and security, because it requires reporting endpoints to opt in to receive reports. I'm hoping that, in future, we might be able to push on this issue a bit more for the various reporting requests I mentioned above and come to an agreement with other browser vendors that it's acceptable to skip preflights -- for example, by defining a reporting Content-Type in the CORS whitelist. If so, we should be able to drop the Expect-CT preflights in future without causing compatibility problems. (This seems preferable to me over, say, shipping without preflights and then later deciding that we do need to send preflights, which could then be incompatible with already-deployed reporting endpoints.)

Again, happy to go into more detail if any of this isn't clear.

[Takeshi Yoshino]

On Tue, Jul 11, 2017 at 1:50 PM, Emily Stark <est...@chromium.org> wrote:

I just remembered there's another compatibility aspect I wanted to draw attention to, which is the somewhat ugly issue of CORS preflights for reports. This is a nuanced issue and I've done my best to summarize all the nooks and crannies succinctly, but please let me know if any of the below isn't clear.

Expect-CT offers a reporting option: a site can register a reporting endpoint, and when it violates the browser's CT policy, the browser will send a report to the reporting endpoint to help the site owner discover and debug CT misconfigurations. This is similar in spirit to CSP reports, HPKP reports, and the not-yet-shipped Reporting API. All of these reports arguably ought to trigger CORS preflights, because they are requests initiated by web content with a non-CORS-safelisted Content-Type header. But none of CSP, HPKP, or the Reporting API implementations do currently trigger preflights. For Expect-CT, the spec leaves it up to the UA to decide whether and how to send preflights for reports.

I didn't want to introduce yet another ad-hoc CORS violation with Expect-CT. But on the other hand, Expect-CT is enforced as part of certificate verification, and it's not particularly viable to construct a meaningful Origin header to send in a preflight request at that point. (Certificate verification is part of connection setup, and the socket may not be bound to an actual request yet.) Therefore, Chrome implements a CORS preflight with a null Origin header that expects an `Access-Control-Allow-Origin: *` header in response before sending Expect-CT reports (which is a perfectly reasonable ACAO header for a publicly accessible reporting endpoint to send).

This null Origin header is a bit ugly, but I believe it's the best option for compatibility and security, because it requires reporting endpoints to opt in to receive reports. I'm hoping that, in future, we might be able to push on this issue a bit more for the various reporting requests I mentioned above and come to an agreement with other browser vendors that it's acceptable to skip preflights -- for example, by defining a reporting Content-Type in the CORS whitelist. If so, we should be able to drop the Expect-CT preflights in future without causing compatibility problems. (This seems preferable to me over, say, shipping without preflights and then later deciding that we do need to send preflights, which could then be incompatible with already-deployed reporting endpoints.)

Again, happy to go into more detail if any of this isn't clear.

All the plan above looks reasonable. Thanks for the detailed explanation.

 

[Jochen Eisinger]

lgtm1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH9hSJaT35tNVdigpZHcR_udmZ%2B0URVFQLFhiF8Puhe2PDQKCQ%40mail.gmail.com.

[Anne van Kesteren]

On Tue, Jul 11, 2017 at 6:50 AM, Emily Stark <est...@chromium.org> wrote:
> This null Origin header is a bit ugly, but I believe it's the best option
> for compatibility and security, because it requires reporting endpoints to
> opt in to receive reports. I'm hoping that, in future, we might be able to
> push on this issue a bit more for the various reporting requests I mentioned
> above and come to an agreement with other browser vendors that it's
> acceptable to skip preflights -- for example, by defining a reporting
> Content-Type in the CORS whitelist. If so, we should be able to drop the
> Expect-CT preflights in future without causing compatibility problems. (This
> seems preferable to me over, say, shipping without preflights and then later
> deciding that we do need to send preflights, which could then be
> incompatible with already-deployed reporting endpoints.)

Is this issue being tracked somewhere?

An alternative might be that we document in Fetch what other requests
servers can expect from browsers that technically violate the
enshrined same-origin policy, but are constrained in enough ways that
it's okayish. The benefit of that is that the server cannot the MIME
type for a report without the appropriate body for that MIME type.
(The downside is that it's a bit of a double standard and makes the
security story a little less clear.)


--
https://annevankesteren.nl/

[Takeshi Yoshino]

On Tue, Jul 11, 2017 at 4:26 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Jul 11, 2017 at 6:50 AM, Emily Stark <est...@chromium.org> wrote:
> This null Origin header is a bit ugly, but I believe it's the best option
> for compatibility and security, because it requires reporting endpoints to
> opt in to receive reports. I'm hoping that, in future, we might be able to
> push on this issue a bit more for the various reporting requests I mentioned
> above and come to an agreement with other browser vendors that it's
> acceptable to skip preflights -- for example, by defining a reporting
> Content-Type in the CORS whitelist. If so, we should be able to drop the
> Expect-CT preflights in future without causing compatibility problems. (This
> seems preferable to me over, say, shipping without preflights and then later
> deciding that we do need to send preflights, which could then be
> incompatible with already-deployed reporting endpoints.)

Is this issue being tracked somewhere?

Discussions I know are the followings:

https://github.com/bifurcation/expect-ct/issues/18

https://github.com/WICG/reporting/issues/41

https://github.com/httpwg/http-extensions/issues/356

 

An alternative might be that we document in Fetch what other requests
servers can expect from browsers that technically violate the
enshrined same-origin policy, but are constrained in enough ways that
it's okayish. The benefit of that is that the server cannot the MIME
type for a report without the appropriate body for that MIME type.

Sentence broken?

Did you intend to suggest we have a special validation on the body of a request with the "application/expect-ct-report" type?

[Anne van Kesteren]

On Tue, Jul 11, 2017 at 9:53 AM, Takeshi Yoshino <tyos...@chromium.org> wrote:
> Discussions I know are the followings:
>
> https://github.com/bifurcation/expect-ct/issues/18
> https://github.com/WICG/reporting/issues/41
> https://github.com/httpwg/http-extensions/issues/356

Thanks, I guess that's sufficient. Though maybe we should open a
tracking issue against Fetch.

>> An alternative might be that we document in Fetch what other requests
>> servers can expect from browsers that technically violate the
>> enshrined same-origin policy, but are constrained in enough ways that
>> it's okayish. The benefit of that is that the server cannot the MIME

cannot get*

>> type for a report without the appropriate body for that MIME type.
>
> Sentence broken?
>
> Did you intend to suggest we have a special validation on the body of a
> request with the "application/expect-ct-report" type?

No, I meant that we would document in Fetch that apart from the
safelisted request thingies servers can also expect this from
browsers. Servers should be moderately safe as the MIME types are
limited and rather special and the bodies are constrained by what
browsers are allowed to produce there. I'm not sure it would be worth
adding that kind of validation so you can actually make such requests
with fetch(). That seems like a lot of effort for little benefit.


--
https://annevankesteren.nl/

[Takeshi Yoshino]

On Tue, Jul 11, 2017 at 5:12 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Jul 11, 2017 at 9:53 AM, Takeshi Yoshino <tyos...@chromium.org> wrote:
> Discussions I know are the followings:
>
> https://github.com/bifurcation/expect-ct/issues/18
> https://github.com/WICG/reporting/issues/41
> https://github.com/httpwg/http-extensions/issues/356

Thanks, I guess that's sufficient. Though maybe we should open a
tracking issue against Fetch.

>> An alternative might be that we document in Fetch what other requests
>> servers can expect from browsers that technically violate the
>> enshrined same-origin policy, but are constrained in enough ways that
>> it's okayish. The benefit of that is that the server cannot the MIME

cannot get*

>> type for a report without the appropriate body for that MIME type.
>
> Sentence broken?
>
> Did you intend to suggest we have a special validation on the body of a
> request with the "application/expect-ct-report" type?

No, I meant that we would document in Fetch that apart from the
safelisted request thingies servers can also expect this from
browsers. Servers should be moderately safe as the MIME types are
limited and rather special and the bodies are constrained by what
browsers are allowed to produce there.

I see. I also basically prefer not to inflate the CORS safelists.

What's your thought about just using the "unsafe-request flag" like SSE for this case? I guess it would just kinda work equivalently to that kind of documentation (though I share your concern that it's currently too easy to misuse it in https://github.com/WICG/reporting/issues/41#issuecomment-311211495).

 

I'm not sure it would be worth
adding that kind of validation so you can actually make such requests
with fetch(). That seems like a lot of effort for little benefit.

Never mind. I just tried to guess what you meant. 

 

[Takeshi Yoshino]

Hmm, I should have said "using the "unsafe-request flag", but also have better documentation".

[Anne van Kesteren]

On Tue, Jul 11, 2017 at 11:23 AM, Takeshi Yoshino <tyos...@chromium.org> wrote:
> Hmm, I should have said "using the "unsafe-request flag", but also have
> better documentation".

Yeah, that seems like the way to go, but we should require standards
that want to use it to file an issue against Fetch or some such so we
can carefully study the implications. Not entirely sure if that's the
right approach or some kind of refactoring is needed. Thoughts
welcome. (In a way this is similar to the Last-Event-ID request header
exception for EventSource.)


--
https://annevankesteren.nl/

[Rick Byers]

LGTM2

Although there's some interop risk here with the implementation-defined aspects of CT policy (and really certificate validation generally), it seems to me this specific API only strictly decreases the overall risks (by increasing visibility / diagnosability).

AFAIK ReportingAPI is pretty close to being ready to ship.  Is the reporting here defined in a way that we can easily spec/implement it on top of (or at least sharing a lot of code / spec-text with) Reporting API?  I know Mike is working to migrate CSP over to the Reporting API, it would be a shame to introduce an additional special model that we need to support forever if Reporting API ends up shipping about the same time that this would.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78gUZuUSFJrqngK%3D-XRzVUs0B1bzo4GtRCS1pos3c0OMYg%40mail.gmail.com.

[Chris Harrelson]

On Tue, Jul 11, 2017 at 10:46 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM2

Although there's some interop risk here with the implementation-defined aspects of CT policy (and really certificate validation generally), it seems to me this specific API only strictly decreases the overall risks (by increasing visibility / diagnosability).

AFAIK ReportingAPI is pretty close to being ready to ship.  Is the reporting here defined in a way that we can easily spec/implement it on top of (or at least sharing a lot of code / spec-text with) Reporting API?  I know Mike is working to migrate CSP over to the Reporting API, it would be a shame to introduce an additional special model that we need to support forever if Reporting API ends up shipping about the same time that this would.

+1 to resolving this question, which seems related to the issue Anne mentioned, before shipping. It doesn't sound great to introduce another special mode.

 

On Tue, Jul 11, 2017 at 6:18 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Jul 11, 2017 at 11:23 AM, Takeshi Yoshino <tyos...@chromium.org> wrote:
> Hmm, I should have said "using the "unsafe-request flag", but also have
> better documentation".

Yeah, that seems like the way to go, but we should require standards
that want to use it to file an issue against Fetch or some such so we
can carefully study the implications. Not entirely sure if that's the
right approach or some kind of refactoring is needed. Thoughts
welcome. (In a way this is similar to the Last-Event-ID request header
exception for EventSource.)


--
https://annevankesteren.nl/

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78gUZuUSFJrqngK%3D-XRzVUs0B1bzo4GtRCS1pos3c0OMYg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_XQakHUvgxSRfJ_Z5TGFW5JPbiZottoEzAo3dexq4_SQ%40mail.gmail.com.

[Emily Stark]

Thanks, Rick. It would be possible to, in future, integrate Expect-CT with the Reporting API, similar to how CSP is doing it (adding a new report-to directive, where browsers that don't understand it will fall back to report-uri). However, I'm a little resistant about using the Reporting API with Expect-CT; here are my thoughts:

- First, the Reporting API retries report-sending, which is a privacy loss that doesn't offer a real benefit in the case of Expect-CT. We wouldn't expect, say, network flakiness to cause CT violations, so retrying report-sending is not a very compelling gain in exchange for the privacy loss.

- Second, the Reporting API is not (AFAIK) ready to ship in that it has the same CORS issues that I mentioned, both in spec and in implementation. Maybe the same null-Origin preflight compromise makes sense for the Reporting API, but OTOH, it might make sense to delay shipping the Reporting API on coming to a more general agreement about exempting certain requests (like reporting requests) from CORS. I don't think it makes sense to delay Expect-CT on this agreement because the longer we wait, the more value from Expect-CT is eroded (as it gives sites less time to experiment with Expect-CT before April).

- Third, while Expect-CT does introduce a new reporting mode, Expect-CT is not meant to live forever; it becomes less and less useful as CT enforcement grows more and more broad. Therefore, I don't expect this reporting mode to last more than a few years before its value becomes small enough that we would stop supporting it.

On Tue, Jul 11, 2017 at 10:46 AM, Rick Byers <rby...@chromium.org> wrote:

[Emily Stark]

Friendly ping: do people have more more comments/concerns about the reporting feature?

[Julia Tuttle]

I like it, but I am biased because more Reporting clients make me happy.

[Rick Byers]

Yeah your response made sense Emily - thanks!  Especially the bit about Expect-CT being a temporary API which we'll remove when CT is fully deployed.  That completely eliminates the concern I had (and would have been obvious if I had thought about it - sorry).

Obviously we need to address the issues you raise properly for Reporting API, but I don't see any compelling reason to block Expect-CT for those issues (beyond ensuring specs are clear for this feature as you and Anne are discussing) and agree shipping it is urgent to reduce compat risk of upcoming CT changes.

Chris, WDYT?

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADyrwZTVuwJEU%3DSYUnXkjvUTtRo2SQ_%3Dkvn2p5pQwDtnJ3juag%40mail.gmail.com.

[Emily Stark]

Thanks, Rick. Chris: friendly ping for your thoughts.

[Chris Harrelson]

Ok. LGTM3. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2SYhZ1VUqERy9b8daQGvUJ%3D64gf58cSLD9CESVeBiCoO7Q%40mail.gmail.com.