CA/Comodo Misissuance Response

On 25th March 2011, in the wake of the Comodo misissuance incident, Mozilla began a wide-ranging discussion about the future of web security. This page links to resources related to that discussion. If you have a researched and carefully written paper on the subject, please feel free to add a link in the appropriate section. (Note that this page is not the venue for the debate - that is here.)

Actions Within the Current Model

The possible things Mozilla could do about this fall into a number of categories:

Changes to Our Root Store

We could:

• Un-trust the root concerned, UTN-UserFirst-Hardware. A preliminary analysis suggests this would affect 205,000 sites, or 13% of the SSL web. However, this figure could be revised (downwards) by cross-signing.
• Un-trust all Comodo's roots.
• Un-trust one or more of their roots, but only for all certificates issued after a particular date. This would require code changes in Firefox or NSS.

Mozilla would be interested in more detailed impact assessments of the above suggestions.

• Remove all roots which are unused, or used below a certain level, on the public internet.

Changes to CA Policy

We could:

• Require that all CAs arrange things so that each RA issues from a different subordinate cert.
• Require that RAs are audited to the same standards as CAs.
• Require that all RA functions are protected by two-factor authentication and/or IP address restrictions.

Changes to NSS

• Fix NSS to allow us to add certs to the store which are specifically untrusted (bug)

Other potential changes:

• Switch to the new PKIX library; this gives us CRL download-on-demand.
• Add a capability to disable roots for all certificates dated after a certain date.
• Implement OCSP stapling.
• Push for and implement an extension to OCSP stapling which allows the stapling of more than one OCSP response.

Changes to Firefox

We could:

• Turn on OCSP "hard fail" by default for everything.
• Turn on OCSP "hard fail" just for EV (currently, we have a soft-fail - EV is downgraded to DV if OCSP fails).
• Change it so that an OCSP failure is a hard failure if the site is using HSTS

OCSP improvement solutions would need to deal with protocol problems such as the current ability to return "try again later".

Future Technologies

Several technologies have been proposed to address perceived shortcomings of the current security model.

HSTS

HTTP Strict Transport Security is a way of forcing a browser visiting a particular site to use HTTPS and never HTTP.

• It has been proposed to extend HSTS to allow the header to specify the CA concerned, thereby segmenting the CA space and reducing the attack surface. (To impersonate the site, you need to compromise the particular CA involved, not just one of those trusted by the browser.)

DNS-based

Several people have proposed validating domain control by placing the certificate, or a hash of it, or other certificate-related information in DNS records. For any of these schemes to be secure, the record would have to be protected by DNSSEC.

• DANE is an RFC draft for certificates-in-DNS; this would allow proof of domain control without the need for a CA
• Do Not Issue allows site owners to say which CAs are permitted to issue certificates for that domain
• HASTLS is an RFC draft to allow a server to advertise secure connection support

TOFU

TOFU stands for "Trust On First Use", also known as the "SSH model" - trust in a certificate is established on first use. Ideally, this would be by confirming the key fingerprint out-of-band; in practice, it's often done by crossing one's fingers and hoping.

• [ Essay from Gervase Markham about self-signed certs]; it explains some of the problems of a TOFU model
• Perspectives is an attempt to mitigate the problems of TOFU using crowdsourcing.
• Monkeysphere