Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/Comodo Misissuance Response: Difference between revisions
no edit summary
(Created page with "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...") |
No edit summary |
||
| Line 1: | Line 1: | ||
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 [https://www.mozilla.org/about/forums/#dev-security-policy here].) | 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 [https://www.mozilla.org/about/forums/#dev-security-policy here].) | ||
== | ==Actions Within the Current Model== | ||
The possible things Mozilla could do about this fall into a number of categories: | The possible things Mozilla could do about this fall into a number of categories: | ||
| Line 43: | Line 43: | ||
* Turn on OCSP "hard fail" just for EV (currently, we have a soft-fail - EV is downgraded to DV if OCSP fails). | * 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 [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] | * Change it so that an OCSP failure is a hard failure if the site is using [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] | ||
OCSP improvement solutions would need to deal with protocol problems such as the current ability to return "try again later". | |||
==Future Technologies== | ==Future Technologies== | ||
| Line 54: | Line 56: | ||
* 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.) | * 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, in | 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 [http://en.wikipedia.org/wiki/DNSSEC DNSSEC]. | ||
* DANE | * [http://www.ietf.org/id/draft-ietf-dane-protocol-06.txt DANE] is an RFC draft for certificates-in-DNS; this would allow proof of domain control without the need for a CA | ||
* [http://tools.ietf.org/html/draft-hallambaker-donotissue-03 Do Not Issue] allows site owners to say which CAs are permitted to issue certificates for that domain | |||
* [http://tools.ietf.org/html/draft-hoffman-server-has-tls-04 HASTLS] is an RFC draft to allow a server to advertise secure connection support | |||
===TOFU=== | ===TOFU=== | ||
| Line 65: | Line 69: | ||
* [ Essay from Gervase Markham about self-signed certs]; it explains some of the problems of a TOFU model | * [ Essay from Gervase Markham about self-signed certs]; it explains some of the problems of a TOFU model | ||
* [http://www.networknotary.org/ Perspectives] is an attempt to mitigate the problems of TOFU using crowdsourcing. | |||
* [http://web.monkeysphere.info/ Monkeysphere] | |||