Certificate Transparency offers several features that competing solutions do not. The following table provides a feature-by-feature breakdown for each technology.
NSC (No side-channels): our experiments show that side-channel requests to third parties during the SSL handshake (e.g. OCSP checks) fail at least 1% of the time, often a great deal more, depending on what protocol they use. This level of failure makes it impossible to hard fail with protocols that use side channels.
IR (Instant recovery from loss of key): if the server loses its private key, can it immediately roll out a new certificate?
GA (Detects Global Attack): if the server is replaced by an evil server that everyone sees, does the protocol protect clients?
TA (Detects targeted attack): if the server is replaced by an evil server (or MitM) for one person or a small number of people, can the protocol protect those people?
NTTP (No trusted third parties): does the protocol avoid the need for the client to trust a third party?
IS (Instant startup): can a new server use a new certificate immediately and be trusted by clients?
US (Unmodified Servers): can it be used without server changes?
(1) CAA is not actually intended for clients, rather it is a signal to other CAs to not issue for a domain. Thus, it provides no defence against rogue CAs.
(2) Assuming the attack was not in progress when the site was first visited by the client
(3) But there’s no way for the client to know if the new site really belongs to the alleged owner.
(4) Server changes are optional in CT - CAs can provide certificates that work with existing servers.
(5) DNS records must be served, DNS server must support DNSSEC. TLSA record must be altered in sync with cert changes.
(6) Server must serve pinning headers.
(7) Some consider DANE to be an alternative to CT, which we disagree with and document here. But DANE could also be used with CT, which seems much more reasonable.