CA/CT Redaction

	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.

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. In addition to the existing policies that allow whitelisting per-domain, Chrome has announced it will allow some limited flexibility for whitelisting by keys, to support organizations with managed CAs for a set of domains. This was part of the reason why Chrome deferred the date for requiring CT to April 2018.

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, the value of which is given different weights by different security professionals. It is noted that hostnames leak in a number of other ways and so the level of obscurity this provides is also disputed; other DNS reconnaissance techniques may well work but be more complex or time consuming than simply consulting a CT server.

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.

Besides, device manufacturers are carefully designing OTA (over the air) updates. If devices has OTA update function with sufficient crypto and security agility, they should able to use name-redaction.

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

IoT devices (cameras, sensors, some car uses, etc.), can be proxies for DOS attacks. Unredacted CT logs may help the DOS attacker to contract botnet for DOS attack.

Response

Why would someone DOS a random camera somewhere else on the Internet 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.

Response

This point assumes that the IoT will be using publicly trusted certificates.

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.
• Competitors scanning CT logs could infer new product/service offerings prior to their public release.

domain label name redaction do not work fine with above problem, but some other redaction mechanisms (i.e. use of name-constrainted intermediate, single entry for STAR certificate) should work.

Response

• How would redaction help? 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.
• Wildcard certificates would suffice for new unreleased services even when being tested publicly. Those could be replaced with fully-qualified certificates (including EV if desired) when the service is announced.

Logging Reveals Personally Identifiable Information

Certificates used for S/MIME, code digning, and digital signatures contain various forms of Personally Identifiable Information (PII).

Response

Currently there are no applications that use and make trust decisions based on SCTs for these types of certificates, and so their consideration is out of scope for this discussion.

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.

Note that this is issue is not caused by redaction. A domain owner today might find an unredacted cert in a CT log that they don't recognize. They need some recourse too, so we don't need a new recourse mechanism/process just for redacted certs.

Problems

Solutions which give the original Applicant 'veto' power means that attackers have power over defenders, which is the wrong balance of concerns.

Solutions which do not allow the original Applicant to 'veto', thus ensuring defenders can mitigate against attackers, run into the complexities identified. The thread covers a number of ways in which the proposed mitigation fails to provide suitable recourse that balances the needs of site operators in the face of both hostile and 'unintentional'/'unauthorized' redaction, and fails to balance the needs of site operators in the face of 'hostile unredaction', which is why recourse is hard.

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. Some CAs may simply choose to redact all certificates or redact by default.

Response

How much visibility and accountability would be lost by redaction? Redaction would hide a few domain labels in the CN and SANs, but every other DN field and every other extension would be present, allowing monitors to detect nearly all the BR-noncompliance they detect today.

Problems

Assessing the risk of misissuance would be significantly complicated. Consider if a single redacted certificate for '(redacted).example.com', it would not be possible to independently assess whether this is a potentially misissued certificate for 'www.example.com' (in which case, the 'example.com' owner may be proactively contacted) or whether it's a sign of an upcoming product release.

For those who believe wildcards are detrimental due to enabling phishing, redaction would introduce a similar method, in the form of '(redacted).example.com' being suitable for login-phishing-page.example.com

For compliance with RFC 5280, a number of CAs were detected to be improperly validating hostnames, allowing situations such as spaces or invalid characters. These would not be possible to detect with redaction.

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.

Domain redaction is not sufficient

While redacting by subdomain labels can address some needs, one case that it does not address is unreleased or unlaunched products. For example, "Contoso Ltd" requires as part of corporate security policy that all of their organizations certificates come from "Contoso Ltd Managed CA". They have an exciting new product to launch, but have not yet announced it, and it will be launched at 'example.com'. Unless it was possible to redact to '(redacted).com', they any disclosure of an 'example.com' certificate being issued by "Contoso Ltd Managed CA" would reveal the affiliation.

While Contoso could restructure their launch such that their product name is a subdomain of their existing domain, to do so would significantly limit their branding opportunities, and Contoso declared this unacceptable.

Redaction is not a security control

Because the unredacted publicly-trusted certificates can be logged, at any time, to a CT log, their ability as a security control is limited to ensuring these certificates are never observed. Unlike DNS observations, which are not widely shared unless they end up within some form of index (such as Shodan or various search engines), and which can be removed or fade away over time, once added to CT logs, unredacted certificates can never be removed.

https://crt.sh/redacted-precertificates already shows a number of examples of the equivalent public certificates having been disclosed via the existing CT log systems, and that's without systems such as browsers automatically submitting publicly trusted certificates to logs to ensure CA's compliance with stated policies.

Alternatives to Redaction

A quick summary of suggestions people have made:

• Disabling CT via browser policy in enterprises
• Private roots
  • As the number of IoT devices increases, number of private roots would increase as well. Managing many private roots is expected to put a burden on users
• Wildcard certs
• Log a name-constrained intermediate
  • As a one of "redaction mechanism", this mechanism was removed from RFC6962-bis with “domain label name-redaction”. Currently, there is not any specification for this mechanism.
• CT-logging anyway