Intent to Implement: Expect-CT header
Emily Stark
(Note: net-dev@ on bcc)
Contact emails
Spec
https://datatracker.ietf.org/doc/draft-stark-expect-ct/
Summary
A new HTTP header that allows websites to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on their connections. By turning on Expect-CT, sites can discover misconfigurations in their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs are discoverable in Certificate Transparency logs.
Motivation
Certificate Transparency (CT) is a system that allows TLS certificates to be audited and monitored in public logs. Chrome is in the process of adopting Certificate Transparency fully, which will allow site owners to discover misissued certificates in CT logs and take action (such as revocation). However, it will be quite a while before Chrome can require CT for all certificates, meaning that site owners cannot yet get the full security benefits of CT. Expect-CT allows security-conscious site owners to opt in to CT enforcement well before CT is fully required for all certificates.
(A common question is "What about Chrome's plan to require CT in October 2017? Won't Expect-CT be useless then?" In October 2017, we plan to require CT for all *new* certs, which does not protect site owners from previously issued bad certificates, or from a bad CA that issues a backdated cert, which has been known to happen.)
Also note that we've had an experimental report-only version of Expect-CT on canary/dev/beta for some time now, for a limited set of sites that are on a baked-in hardcoded list. This Intent introduces an HTTP header for Expect-CT (allowing any site to opt in to the feature without being on the hardcoded list) and an enforcement mode (allowing sites to specify that they want connections to be closed, not merely reported, if they are not CT-compliant).
Interoperability and Compatibility Risk
Interop: The main interoperability risk of this feature is that it is up to the browser to decide details of CT enforcement, e.g. how many SCTs are required and from what CT logs. Thus, a certificate that satisfies the CT policy of one browser may not satisfy the CT policy of another. However, this is an interop risk of CT in general, and not specific to Expect-CT; multiple browsers are in the process of implementing CT fully and working closely together to develop CT policies that are harmonious.
Compatibility: There is no compat risk for existing web content, since Expect-CT is an opt-in feature. Much like other opt-in security features such as HSTS and HPKP, Expect-CT presents an opportunity for a footgun, in that a site might turn on Expect-CT, but due to misconfiguration or misunderstanding, serve a certificate that is not CT compliant, resulting in the site becoming inaccessible in Chrome until the Expect-CT configuration expires. We are minimizing this risk by supporting a reporting mode, in which a site owner will receive reports if their site becomes inaccessible due to Expect-CT.
Ongoing technical constraints
No
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5677171733430272
Requesting approval to ship?
No
rsl...@chromium.org
On Friday, January 6, 2017 at 12:34:39 PM UTC-8, Emily Stark wrote:
(Note: net-dev@ on bcc)
Contact emails
Spec
Also note that we've had an experimental report-only version of Expect-CT on canary/dev/beta for some time now, for a limited set of sites that are on a baked-in hardcoded list. This Intent introduces an HTTP header for Expect-CT (allowing any site to opt in to the feature without being on the hardcoded list) and an enforcement mode (allowing sites to specify that they want connections to be closed, not merely reported, if they are not CT-compliant).
Interoperability and Compatibility Risk
Interop: The main interoperability risk of this feature is that it is up to the browser to decide details of CT enforcement, e.g. how many SCTs are required and from what CT logs. Thus, a certificate that satisfies the CT policy of one browser may not satisfy the CT policy of another. However, this is an interop risk of CT in general, and not specific to Expect-CT; multiple browsers are in the process of implementing CT fully and working closely together to develop CT policies that are harmonious.
Compatibility: There is no compat risk for existing web content, since Expect-CT is an opt-in feature. Much like other opt-in security features such as HSTS and HPKP, Expect-CT presents an opportunity for a footgun, in that a site might turn on Expect-CT, but due to misconfiguration or misunderstanding, serve a certificate that is not CT compliant, resulting in the site becoming inaccessible in Chrome until the Expect-CT configuration expires. We are minimizing this risk by supporting a reporting mode, in which a site owner will receive reports if their site becomes inaccessible due to Expect-CT.
Emily Stark
On Friday, January 6, 2017 at 12:34:39 PM UTC-8, Emily Stark wrote:(Note: net-dev@ on bcc)
Contact emails
Spec
As this is being pushed through the IETF DataTracker, where's the best way to send feedback? Is there a GitHub repository? As it's an individual submission, I'm assuming there isn't an IETF WG that has adopted this.
Also note that we've had an experimental report-only version of Expect-CT on canary/dev/beta for some time now, for a limited set of sites that are on a baked-in hardcoded list. This Intent introduces an HTTP header for Expect-CT (allowing any site to opt in to the feature without being on the hardcoded list) and an enforcement mode (allowing sites to specify that they want connections to be closed, not merely reported, if they are not CT-compliant).
What details can you share about the results of those experiments? Has anything resulted in those that has increased or decreased confidence in going to a wider release?
Interoperability and Compatibility Risk
Interop: The main interoperability risk of this feature is that it is up to the browser to decide details of CT enforcement, e.g. how many SCTs are required and from what CT logs. Thus, a certificate that satisfies the CT policy of one browser may not satisfy the CT policy of another. However, this is an interop risk of CT in general, and not specific to Expect-CT; multiple browsers are in the process of implementing CT fully and working closely together to develop CT policies that are harmonious.
I'm only aware of Mozilla and Google participating on ct-p...@chromium.org. Were you thinking of more vendors?
We've already seen significant divergence being discussed between the Mozilla and Google policies. Does the introduction of this feature (unintentionally) ossify the policy in a way that benefits Google, but (effectively) discourages either Mozilla's policy or implementation of Expect-CT?
Compatibility: There is no compat risk for existing web content, since Expect-CT is an opt-in feature. Much like other opt-in security features such as HSTS and HPKP, Expect-CT presents an opportunity for a footgun, in that a site might turn on Expect-CT, but due to misconfiguration or misunderstanding, serve a certificate that is not CT compliant, resulting in the site becoming inaccessible in Chrome until the Expect-CT configuration expires. We are minimizing this risk by supporting a reporting mode, in which a site owner will receive reports if their site becomes inaccessible due to Expect-CT.
Does this fully capture the compat risks? It would seem like any potential changes to the spec may result in UAs applying different policies or failing to apply Expect-CT policies.
Who (IETF? W3C TAG? security-dev@?) will be performing the security analysis? For example, the introduction of an additional 'footgun' or the requirement that only a single occurrence of the header is respected.
Ryan Sleevi
I'd argue that the policy is already fairly ossified; making it stricter would already be a major headache, since CT is already enforced for Symantec certificates and required for EV UI,
and CAs are presumably already planning/making changes to support the Chrome policy in October.
Compatibility: There is no compat risk for existing web content, since Expect-CT is an opt-in feature. Much like other opt-in security features such as HSTS and HPKP, Expect-CT presents an opportunity for a footgun, in that a site might turn on Expect-CT, but due to misconfiguration or misunderstanding, serve a certificate that is not CT compliant, resulting in the site becoming inaccessible in Chrome until the Expect-CT configuration expires. We are minimizing this risk by supporting a reporting mode, in which a site owner will receive reports if their site becomes inaccessible due to Expect-CT.
Does this fully capture the compat risks? It would seem like any potential changes to the spec may result in UAs applying different policies or failing to apply Expect-CT policies.Can you elaborate on this point? Since the spec doesn't specify a particular policy, I don't see how changes to the spec would result in UAs applying different policies.