Difference between revisions of "CA/CT Redaction"
(More draftiness) |
(First version) |
||
| Line 9: | Line 9: | ||
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document. | CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document. | ||
| − | ==== Response ==== | + | ===== Response ===== |
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots. | In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots. | ||
| Line 17: | Line 17: | ||
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track. | Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track. | ||
| − | ==== Response ==== | + | ===== Response ===== |
This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways. | This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways. | ||
| Line 27: | Line 27: | ||
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. | "Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. | ||
| − | ==== Response ==== | + | ===== Response ===== |
| − | Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. | + | Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. The WebPKI should only be used by modern, routinely-updated, security-patched devices in order for us to be able to keep our crypto and security agility. |
=== Makes DOS Easier === | === Makes DOS Easier === | ||
| Line 35: | Line 35: | ||
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. | For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. | ||
| − | ==== Response ==== | + | ===== Response ===== |
Why would someone DOS a random camera just because it was there? | Why would someone DOS a random camera just because it was there? | ||
| − | === | + | === Logging Reveals Geolocation Information === |
| − | For some IoT devices (cameras, sensors, etc.), | + | For some IoT devices (cameras, sensors, etc.), geolocation information is very sensitive. However, IoT manufacturers may want to put geolocation information into the certificate to make management of large numbers of devices easier. This leads to a desire for redaction so the attacker does not have both the server's addressable name and its location. |
| − | === | + | === Logging Reveals Commercially Sensitive Information === |
| − | |||
| − | |||
| − | |||
| − | |||
Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private. | Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private. | ||
| − | ==== Response ==== | + | ===== Response ===== |
| − | How? | + | How? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged. |
== Against == | == Against == | ||
| Line 61: | Line 57: | ||
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post]. | It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post]. | ||
| − | == Alternatives == | + | ===== Response ===== |
| + | |||
| + | Such concerns can be addressed by requiring each CA which uses redaction to have a public process whereby domain owners (who would need to be validated as such) can apply for information about redacted certificates for their domains, and request revocation if they wish. This would need to give the original Applicant for the certificates the right of objection and so could not be an instant or near-instant process. | ||
| + | |||
| + | === Redaction Makes Clients More Complex === | ||
| + | |||
| + | CT redaction would reduce internet security by increasing the complexity and bug surface of SCT-consuming clients (such as browsers and monitors) and SCT-producing systems (such as CAs). | ||
| + | |||
| + | === Redaction Reduces Visibility and Accountability To The Public === | ||
| + | |||
| + | CT redaction would reduce internet security due to a loss of visibility and accountability in the Web PKI. This would reduce the value of CT logs to the ecosystem. There is a strong likelihood of "over-redaction", where enterprises choose to redact certificates by default out of misplaced security concerns. | ||
| + | |||
| + | === Redaction Reduces Visibility and Accountability to Domain Owners === | ||
| + | |||
| + | There are a variety of situations in which domain owners may lose visibility what certificates are authorized for their own hostnames, either through domain transfers or acquisitions, or through governance issues in sufficiently large enterprises. | ||
| + | |||
| + | == Alternatives to Redaction == | ||
| + | |||
| + | A quick summary of suggestions people have made: | ||
| − | * Disabling CT via browser policy | + | * Disabling CT via browser policy in enterprises |
* Private roots | * Private roots | ||
* Wildcard certs | * Wildcard certs | ||
| + | * Log a name-constrained intermediate | ||
* CT-logging anyway | * CT-logging anyway | ||
Revision as of 15:01, 21 November 2017
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.
Contents
For
Enterprise Users Are Requesting It
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.
Response
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots.
Concealing Network Topography
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track.
Response
This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways.
As for multiple wildcard certs being hard to track, they would have different serial numbers, so automated provisioning software could tell them apart without difficulty.
IoT Usage
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.
Response
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. The WebPKI should only be used by modern, routinely-updated, security-patched devices in order for us to be able to keep our crypto and security agility.
Makes DOS Easier
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.
Response
Why would someone DOS a random camera just because it was there?
Logging Reveals Geolocation Information
For some IoT devices (cameras, sensors, etc.), geolocation information is very sensitive. However, IoT manufacturers may want to put geolocation information into the certificate to make management of large numbers of devices easier. This leads to a desire for redaction so the attacker does not have both the server's addressable name and its location.
Logging Reveals Commercially Sensitive Information
Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.
Response
How? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged.
Against
Recourse is Hard
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in this CT policy post.
Response
Such concerns can be addressed by requiring each CA which uses redaction to have a public process whereby domain owners (who would need to be validated as such) can apply for information about redacted certificates for their domains, and request revocation if they wish. This would need to give the original Applicant for the certificates the right of objection and so could not be an instant or near-instant process.
Redaction Makes Clients More Complex
CT redaction would reduce internet security by increasing the complexity and bug surface of SCT-consuming clients (such as browsers and monitors) and SCT-producing systems (such as CAs).
Redaction Reduces Visibility and Accountability To The Public
CT redaction would reduce internet security due to a loss of visibility and accountability in the Web PKI. This would reduce the value of CT logs to the ecosystem. There is a strong likelihood of "over-redaction", where enterprises choose to redact certificates by default out of misplaced security concerns.
Redaction Reduces Visibility and Accountability to Domain Owners
There are a variety of situations in which domain owners may lose visibility what certificates are authorized for their own hostnames, either through domain transfers or acquisitions, or through governance issues in sufficiently large enterprises.
Alternatives to Redaction
A quick summary of suggestions people have made:
- Disabling CT via browser policy in enterprises
- Private roots
- Wildcard certs
- Log a name-constrained intermediate
- CT-logging anyway
