CA/CT Redaction: Difference between revisions

CA/CT Redaction (view source)

Revision as of 15:23, 1 December 2017

1,357 bytes added , 1 December 2017

→‎Against: Updated response to "Recourse" to make it clear it's not responding to the thread points, but also added notes about "Contoso's" use case and "hostile logging" if redaction is accepted

Rsleevi

21

edits

@@ Line 73: / Line 73: @@
 ===== Problems =====
-While process is beneficial, the identified options are either "unredact" or "revoke". Solutions that involve "unredact" undermine the various arguments in favor of redaction, such as preventing network topology enumeration, as a single temporary DNS takeover (or BGP redirect) could result in full enumeration. Solutions that involve "revoke" create even greater risk if temporary control can result in complete revocation, but also can result in situations where the certificate was legitimately requested and redacted, but not through the appropriate internal channels, results in improper revocation by the subscriber.
-Thus processes for domain unredaction or unrevocation need to consider whether all of the arguments in favor of redaction can be satisfied with such a process, and if processes like multiple observations or continuous observations over a sustained period of time are used, whether they end up harming security more than helping.
+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 ===
@@ Line 100: / Line 101: @@
 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 ==