Fwd: Intent to Implement: Expect-CT header
Eran Messeri
From: Emily Stark <est...@chromium.org>
Date: Fri, Jan 6, 2017 at 8:34 PM
Subject: Intent to Implement: Expect-CT header
To: blink-dev <blin...@chromium.org>
(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
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPP_2SaT_Kq5vh26o%3DD04TB5HOjZ3BFAMb1rX3zdffhKYtc-3w%40mail.gmail.com.